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=32360>. 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=32360 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-31 11:11 ------- Allow me to explain the way I see things, since I opened the BUG in the first place. First off, the setDefaultNamespaceIgnored() solution is NOT a solution to the problem I was originally reporting. From the comments in this bug I cannot tell exactly what this method even does - it seems to simply deactivate namespace matching for nodes in the default namespace? However, as I understand it, it is a requirement for the Forrest project, and since it is not enabled by default it has its justification. Secondly, having read the standard and all kinds of comments and articles linked to by this bug, I agree that the original implementation of JXPath was Standards conformant. HOWEVER, I still argue that it is not exactly what we want - in other words, the standard is wrong! (And in fact, in XPath 2.0 it has been modified). The problem is that there is a mismatch/assymmetry in the interface concerning the default namespace and the 'default' (null) prefix: In XML the default prefix can be mapped to any namespace, eg: xmlns="http://a"; -> namespace a mapped to default prefix However, in XPath, I cannot map any namespace to the default prefix: registerNamespace(null,"http://a";) --> this is an error This 'mismatch' has the consequence, for example, that I CANNOT write XML documents with 'embedded' XPath expressions using the 'default' prefix, eg: <doc xmlns="http://a";> <item id="123">...</item> ... (more content) ... <itemref xpath="//[EMAIL PROTECTED]"/> ... (more content) ... </doc> This would be a very natural (and compact) way to write the document, however it is not valid, since the unprefixed XPath expression '//item' will not match the namespace of our item, which is 'http://a'. THAT is the basic problem, and it is both subtle and ugly -> it prevents the use of XPath in the intuitive way. My Proposal would be to treat both the default prefix and the default (no namespace) namespace as 'fully fledged' members in the mapping process. Thus my proposal to permit calls like: registerNamespace(null,"http://foo";) --> assigns namespace to default prefix registerNamespace("foo",null) --> assigns prefix to default namespace This is not exactly XPath 1.0 spec conformant, but it is completely 'backwards compatible' in the sense that if you do not register default prefix or namespace the behaviour would be as before. To make the difference more clear, one could keep the interface of registerNamespace() as it is, and instead add methods like: registerDefaultPrefix() registerDefaultNamespace() which would make the usage easier to understand... This might also get us prepared for XPath 2.0, which allows registering a default namespace. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
