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 17:05 ------- It is not OK for an XPath API to provide a switch that basically says, "Stop doing what the specification clearly says it shoudl do and do something else instead." There are no deficiencies in XPath namespace handling. XPath 1.0's namespace handling is complete. Nothing is missing. Nothing extra is needed. You're also failing to see the problems this introduces. Consider this example: <test xmlns="http://test"; foo="bar"/> If one maps the null prefix to http://test then how does one address the foo attribute? It is not in a namespace. Do we assing a prefix to the empty string namespace? That is, do we then do xmlns:att="" and write an expression like /test/@att:foo ? However, in Namespaces 1.0 the empty string may not be assigned to a prefix. That is, xmlns:att="" is illegal, so this is even more broken. To the extent there is a real issue here (and I'm not yet convinced there is one) it is a disagreement with a deliberate design decision in XPath 1.0. JXPath is the wrong place to address this. One would expect a Java compiler to correctly implement the Java specification and not provide switches to behave in a nonconfiormant fashion. One similarly expects an XPath library to correctly implement the XPath specification. -- 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]
