DO NOT REPLY [Bug 34819] - [digester] NodeCreateRule Failing

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DO NOT REPLY [Bug 34819] - [digester] NodeCreateRule Failing

Bugzilla from bugzilla@apache.org
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=34819>.
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=34819





------- Additional Comments From [hidden email]  2005-05-27 09:31 -------
Ok, I checked the SAX specs and it is clear that when namespace parsing is off,
it is OPTIONAL for the parser to provide localname in callbacks. See the javadoc
for method startElement here:
   http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html

But NodeCreateRule *assumes* that if localname is non-null then namespace
parsing is enabled and it should therefore generate DOM2 nodes. Clearly Xerces
doesn't provide localname, so parsing with namespace-aware=false results in DOM1
nodes.

However it seems that Aelfred provides localname even when namespace-aware is
false. And the specs say this is allowed.

So question: should we generate DOM1 or DOM2 nodes when parsing with Aelfred and
namespace-aware false? We do have the information available to generate DOM2
nodes (I think). But this would be inconsistent with the behaviour of other
parsers, so I think that we should generate DOM1 *always* when namespace-aware
is false.

So I believe that this qualifies as a bug in NodeCreateRule.

Jack, I've attached a patch. Could you try this with Aelfred and see what happens?

Note: there is *potentially* a change in behaviour (ie breaks existing code). I
don't think it does, but I would appreciate a review of this code by someone
before I commit it to Digester.

--
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: [hidden email]
For additional commands, e-mail: [hidden email]