Re: [xml-dev] RE: [Sax-devel] Re: SAX survey: expected local name for non-namespace qualified elements

[Joseph Kesselman/Watson/IBM <ke...@us.ibm.com>]

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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: [xml-dev] RE: [Sax-devel] Re: SAX survey: expected local name for non-namespace qualified elements

[Karl Waclawek <ka...@waclawek.net>]

> 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?

My vote goes for QName = LocalName for the above case.

> 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 would say that when NS processing is turned off, the namespace standard
is not applicable, so neither LocalName nor QName have a defined meaning,
there is only a Name.
But the question is: if we use one API for both, how do we assign
the roles to the parameters in each case (NS processing on or off).
 
> 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.

I agree that QName maps to Name. But the real problem is that we have
to find definitions for QName and LocalName that work unambiguously in both cases.
I found the approach used in Expat more practical, since it doesn't care about
QNames and LocalNames, it just returns an NS-URI, a Name and a Prefix.
That works well if NS processing is on, and just as well if it is off.
 
> 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.

It's up to us which roles we assign to QName and LocalName in
the NS-unaware mode, since none of them is defined there.
So, why not make them equal?

Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org