David Brownell wrote: > Karl Waclawek wrote: > > > > I understand it the same way. The confusion in this thread really is: > > if NS processing is off, then which should really represent the > > element name - qName or localName? I agree with you that localName is > > the more natural candidate. > > Actually that'd be a new confusion. The original question dealt with > the namespacing-on-but-no-namespace case, where the SAX spec says both > URI and localName must be provided (or neither) ... even though some > implementations are providing a localName with empty URI.
Well, in that case the question is: What does it mean if "no URI is provided". If you allow URIs to be empty strings, then you will always have an URI, if you say that an empty URI string means that there is no URI, (which seems correct to me) then localName must be empty too, but if namespace-prefixes is false, qName is optional, and you have no place "obligated" to report the name. Even if you would have to use qName then, I find it still not elegant that you have to switch between localName and qName depending on whether the element name is in a namespace or not. How much less confusing the Expat approach is: You pass: -URI -Name -Prefix It's always clear what goes where. > > Arnaud's point (that localName is not defined except in the context > of namespacing) is IMO good. Conformant code was _never_ allowed to > rely on localName in such cases. Well, qName is also not defined outside of namespacing. What does "qualified" mean when NS processing is off? I still say that localName sounds less bound to namespaces then qName. What's the problem if we make localName and qName always available, and they are the same if there is no namespace. Karl --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
