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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
