[ http://issues.apache.org/jira/browse/XALANJ-2335?page=comments#action_12448337 ] Mike Brown commented on XALANJ-2335: ------------------------------------
It depends on how you define "really important". I can work around it, but I don't see why I shouldn't expect Xalan to follow the XPath 1.0 data model when processing an XSLT 1.0 stylesheet. In a real-world web application, I am using XSLT to produce a manual serialization of an XML fragment. I generate a text node representing the fragment in XML syntax, and this gets put into a textarea in my stylesheet's HTML output. When I process an element node to generate its start-tag, I first generate a namespace declaration for the default namespace, if necessary. Then I set out to generate namespace declarations for any prefixes that are in scope. To this end, I process the element's namespace nodes that bind non-empty prefixes. For each of these namespace nodes, I decide whether to emit a namespace declaration depending on whether the same binding is in effect on the element's parent. So, when processing the namespace nodes, I need to access their parents and grandparents. My first inclinaton was to use the parent axis to get to those nodes, but I found that Xalan gives me the wrong ones. I can work around it by binding the parent element to a variable that I reference when processing the namespace nodes, but I shouldn't have to do that. IMHO this isn't really a duplicate of the other issues you mention. Yes, they have the same root cause -- a decision to ignore the requirement that each element has a unique set of namespace nodes -- but the symptom of the parent/ancestor axes being unreliable relative to a namespace node is distinct from the symptom of the namespace node ID not being unique (issues 1325/1962/2080) and the symptom of namespace nodes not existing along the namespace axis at all (issue 334, which has actually been fixed). I'd expect addressing these different symptoms to have different priorities, even if they'd ideally be resolved in one fell swoop. When those issues were ignored or declared "wont fix" as far back as 2001, it was in anticipation of XSLT 2.0 legitimizing Xalan's practice of not defining as many namespace nodes as required ...and apparently in anticipation of XPath/XSLT 2.0 rendering 1.0 a historical curiosity overnight. But this "why bother since XSLT2 is coming" reasoning has proven to be unsound. First, this is an XPath/XSLT 1.0 processor (thank goodness). As long as it processes stylesheets that declare their version to be 1.0, I expect it to behave like a 1.0 processor is supposed to behave. The features planned for XPath/XSLT 2.0 do not change what is required of an XPath/XSLT 1.0 processor. The 1.0 data model is still in effect. Second, here we are 5 years later, and not only is XPath/XSLT 2.0 still unfinished and considered by many to be overkill, but it's pretty clear that even if you were going to support the 2.0 data model, you'd still have to fix the bugs because XPath 2.0 actually won't change the behavior of the namespace axis at all; it'll just make supporting it optional, since it'll provide an alternative method of accessing namespace bindings. Namespace nodes, if supported, will still have to have unique IDs and will have to have the correct parents (this is explicit in XPath 2.0 sec. 6.4.1). Mike > Xalan-J incorrectly identifies the parents of namespace nodes > ------------------------------------------------------------- > > Key: XALANJ-2335 > URL: http://issues.apache.org/jira/browse/XALANJ-2335 > Project: XalanJ2 > Issue Type: Bug > Components: XPath > Affects Versions: 2.7 > Reporter: Mike Brown > Priority: Minor > > Xalan-J 2.7.0 incorrectly identifies the parents of namespace nodes. > A namespace node's parent is supposed to be the element the namespace node is > associated with. > In Xalan, for a namespace node with an empty local-name, parent::* > incorrectly identifies the grandparent element. And for a namespace node with > local-name 'xml', parent::* incorrectly identifies the document element in > every case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
