commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 33780] - [betwixt] SAX Attribute Problem: qName differ from localName
Date Tue, 01 Mar 2005 02:18:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33780>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33780





------- Additional Comments From skitching@apache.org  2005-03-01 03:18 -------
Hi Christoph,

While the qname in the attributes does seem odd to me, you should note that when
using a namespace-aware sax parser to parse text input, there is no guarantee
that the qname field is populated at all. At least, that's my interpretation of
the javadoc

>From the javadoc for the org.xml.sax.Attributes.getQName method:
 Returns:
  The XML 1.0 qualified name, or the empty string if none is available, ...

Code processing attributes really should do:
  if (localname.size() > 0) {
    // we are using a namespace-aware parser, so use
    // (URI, localname). Don't use the qname, as it might
    // or might not be defined, at the discretion of the parser
    // implementation...
  } else {
    // we are using a non-namespace-aware parser, so
    // use the qname
  }

If cocoon is looking at the qname field when the localname is not empty, then I
believe that cocoon needs fixing.

Note that if the "namespace-prefixes" attribute is set on the sax parser, then
qnames are definitely available - but namespace declarations *also* get passed
as attributes, which is not normally desired.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message