To return to the subject: Is there anyone still asserting that when namespace processing is turned on, a non-qualified element's local name is _not_ equal to its Qname, with both being the name as entered? I've seen several folks say it _isn't_ what they expect, and the Namespaces grammar bears that out:
[6] QName ::= (Prefix ':')? LocalPart
Are there any remaining sticking points, or have we reached consensus on that?
The other items being discussed seem to be related to the fact that both namespace-aware and -unaware views of a document are possible. That's somewhat orthogonal to the above point.
Personal reactions:
I agree with the assertion that when namespace processing is turned off, localname is not defined by the namespace standard, and applications should be consistant: either turn the feature on, or don't look at that value.
I also agree that -- given how namespaces were patched into the XML grammar, Namespace productions 9-12 -- the value which Namespaces called QName *IS* the value which XML 1.0 called Name, and that QName is the right place to return the full/raw/possibly-qualified name in either mode.
Re whether the localname should be best-approximation or null when running in the namespace-unaware mode... Theoretically this shouldn't matter since this combination is a programming bug; see first paragraph. Since it _is_ a bug, the single greatest advantage of returning empty/null is that it will probably cause code to break, thus advising the developer that they forgot to turn on namespace processing.
The DOM is a slightly different case because it can intermix namespace-aware and namespace-unaware nodes in a single document. This came out of a requirement to let namespace-unaware applications operate on namespace-aware documents, at the cost of not being able to safely use the namespace-aware view thereafter. It was a necessary kluge, but it IS a kluge and I would strongly recommend against SAX repeating that decision.
______________________________________
Joe Kesselman / IBM Research
