[XML-SIG] Signature of startElement

[tpassin@home.com]

Martin v. Loewis wites -

> When integrating PyXML and Python 2, I noticed a serious problem:
>
> The signature of startElement must be determined. In Python 2, it
> takes two arguments (name, attrs); in PyXML, it takes three arguments
> (name, qname, attrs). There must be a definite decision for Python 2,
> then PyXML must be updated to reflect this decision. If there is no
> change to Python 2 in that area within a few days, I'll update PyXML
> to reflect the current state of Python 2.
>
> Please note that this signature business must be determined regardless
> of whether there are two xml packages or one: Applications must be
> able to trust the SAX2 API; they cannot provide different handlers for
> different parsers (this is the whole point of SAX).
>
> I don't have any opinion on that question; I just observe that in
> Java, the signature is
>
> startElement(java.lang.String namespaceURI, java.lang.String localName,
>              java.lang.String qName, Attributes atts)
>
> Not being an expert in XML namespaces, I have a hard time relating
> either of the existing signatures or the SAX2 Java signature to the
> proposal in
>
> http://www.python.org/pipermail/xml-sig/2000-July/004650.html
>
> so I'd appreciate if somebody shared a few words about how that
> interface should look like.

I think that Lars' post, which you referenced, was right on target, although
I was one of those who liked using prefixes better than qnames.  Separate
methods for NS- and nonNS-aware methods.  That's how the DOM is doing it,
and it lets us have backward compatibility.

What we don't want to do is get rid of qnames/prefixes in the name of
consistency with the current (or beta 2) library if the latter doesn't
understand namespaces.  We've got to be able to get namespaces into the
distribution some way.

Not to tell the man who's doing it what to do, but if we can get Lars'
proposal implemented, and keep the **non-NS-aware** methods consistent with
the same methods in the Python 2 library, we'll be in good shape.  Does this
make sense, or am I missing something?

Thanks for your work,

Tom Passin