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=23955>. 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=23955 unique attributes with same qname conflict resolution is incorrect ------- Additional Comments From [EMAIL PROTECTED] 2004-06-02 04:04 ------- Here is the original more or less: <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 foo:attr="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar2"/> <!-- line 4 --> </elem2> </elem1> </xsl:template> elem1 has the namespace mapping (or node) "foo"-> "bar1". In the construction of elem2 this mapping or node is inherited so elem2 has the same namespace node "foo" -> "bar1". Then we add an attribute (the <xsl:attribute...>) This xsl:attribute element is the name "foo:attr" but with "foo" mapping to "bar2". Now during the construction of elem2 we have a collision ... ouch. Here is what happens for Xalan-J interpretive during its construction: 1 - element "elem1" exists at depth 1 2 - startPrefixMaping call . . . but this is the kind after the element name (unlike classical SAX call) "foo" maps to "bar1" so this mapping applies to elem1 and all children of elem1 3 - element "elem2", child of "elem1" exists at depth 2 4 - the current element "elem2" has an attribute of foo:attr="1" (.... serializer checks out if "foo" maps to anything, ... it does ... a mapping for it exists at depth 1 things are looking good) 5 - add a namespace mapping for elem2 at depth 2, "foo" maps to "bar2" ( serializer dutifully over-rides the "foo" mapping of the parent that would otherwise be inherited) 6 - add an attribute to the current element "elem2" namely foo:attr="" is added to elem2 (.... serializer checks out if "foo" maps to anything, ... it does ... a mapping for it exists at depth 2 things are looking good ... well not really) The output should look something like this: Here is the original more or less: <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 foo:attr="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar2"/> <!-- line 4 --> </elem2> </elem1> </xsl:template> elem1 has the namespace node "foo"-> "bar1". In the construction of elem2 this mapping or node is inherited so elem2 has the same namespace node "foo" - > "bar1". Then we add an attribute (the <xsl:attribute...>) This xsl:attribute element is the name "foo:attr" but with "foo" mapping to "bar2". Now during the construction of elem2 we have a collision ... ouch. The serializer is not at fault. Here is what it is told from Xalan-J interpretive during its construction: 1 - element "elem1" exists at depth 1 2 - oh yah, I forgot to mention a startPrefixMaping call . . . but this is the kind that I tell you about after I told you about the element name (unlike classical SAX call) "foo" maps to "bar1" 3 - element "elem2" exits at depth 2 4 - the current element "elem2" has an attribute of foo:attr="1" (.... serializer checks out if "foo" maps to anything, ... it does ... a mapping for it exists at depth 1 things are looking good) 5 - oh yah, I forgot to mention a prefix mapping for elem2 at depth 2, "foo" maps to "bar2" ( serializer dutifully over-rides the "foo" mapping) 6 - the current element "elem2" has an attibute of foo:attr="" (.... serializer checks out if "foo" maps to anything, ... it does ... a mapping for it exists at depth 2 things are looking good ... well not really) The output should look something like this: <elem1 xmlns:foo="bar1"> <elem2 foo:attr="1" xmlns:ns0="bar2" ns0:attr=""/></elem1> Initally I thought that if prefix "foo" hadn't been used on line 3 (<!-- line 3 -->) that I would use the prefix "foo" on line 4. For example if the stylesheet were: <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 attr1="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar2"/> <!-- line 4 --> </elem2> </elem1> </xsl:template> Then the output would be: <elem1 xmlns:foo="bar1"><elem2 xmlns:foo="bar2" foo:attr="" attr1="1" ></elem2></elem1> But initially the namespace node ("foo" maps to "bar2") applies only to the attribute, during construction the attribute gets hoisted up from being a child element of elem2 to being on the same footing as other attributes that elem2 and in doing so this namespace mapping gets more exposed. Due to the inheritance of namespace nodes in serialized XML documents and due to not being able to un-declare such mappings, this example would be problematic: <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 attr1="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar2"/> <!-- line 4 --> <elem3 foo:att3="3" /> </elem2> </elem1> </xsl:template> The namespace node on line 4 should now not be exposed when attibutes are colleced for elem2, because this mapping of "foo" to "bar2" would mask the one on line 2 and elem3 would not inherit the right mapping. The serializer runs on the fly and doesn't know if elem3 (or deeper children) are comming or not, or whether they might use the prefix "foo" or not. So my conclusion is that during such construction, if the prefix mapping already exists and is to the same URI then use the prefix, e.g. <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 attr1="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar1"/> <!-- line 4 --> <elem3 foo:att3="3" /> </elem2> </elem1> </xsl:template> and output this: <elem1 xmlns:foo="bar1"><elem2 foo:attr="" attr1="1" ><elem3 foo:attr3="3" /></elem2></elem1> but otherwise do not use the prefix from the name in the xsl:attribute element at all because it will pollute the namespace mappings. Initally I thought that if prefix "foo" hadn't been used on line 3 (<!-- line 3 -->) that I would use the prefix "foo" on line 4. For example if the stylesheet were: <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 attr1="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar2"/> <!-- line 4 --> </elem2> </elem1> </xsl:template> Then the output would be: <elem1 xmlns:foo="bar1"><elem2 xmlns:foo="bar2" foo:attr="" attr1="1" ></elem2></elem1> But initially the namespace node ("foo" maps to "bar2") applies only to the attribute, during construction the attribute gets hoisted up from being a child element of elem2 to being on the same footing as other attributes that elem2 and in doing so this namespace mapping gets more exposed. Due to the inheritance of namespace nodes in serialized XML documents and due to not being able to un-declare such mappings, this example would be problematic: <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 attr1="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar2"/> <!-- line 4 --> <elem3 foo:att3="3" /> </elem2> </elem1> </xsl:template> The namespace node on line 4 should now not be exposed when attibutes are colleced for elem2, because this mapping of "foo" to "bar2" would mask the one on line 2 and elem3 would not inherit the right mapping. The serializer runs on the fly and doesn't know if elem3 (or deeper children) are comming or not, or whether they might use the prefix "foo" or not. So my conclusion is that during such construction, if the prefix mapping already exists and is to the same URI then use the prefix, e.g. <xsl:template match="/"> <elem1 xmlns:foo="bar1"> <elem2 attr1="1"> <!-- line 3 --> <xsl:attribute name="foo:attr" xmlns:foo="bar1"/> <!-- line 4 --> <elem3 foo:att3="3" /> </elem2> </elem1> </xsl:template> and output this: <elem1 xmlns:foo="bar1"><elem2 foo:attr="" attr1="1" ><elem3 foo:attr3="3" /></elem2></elem1> XSLTC may be a different story. - Brian Minchau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
