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=29488>. 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=29488 Multiple problems with collecting xsl:attributes with over-ridden values and prefix/URI maps Summary: Multiple problems with collecting xsl:attributes with over-ridden values and prefix/URI maps Product: XalanJ2 Version: CurrentCVS Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: org.apache.xml.serializer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The serializer has a problem that it identifies attributes by their qname (prefix:localName) note by their expanded qname (URI and localName). It also sometimes replaces existing namespace mappings while processing xsl:attribute elements. Other bugs are already opened for this, namely bug 23897 and bug 23955. This needs a bit of a design change because currently there is no way to tell the serializer that attributes are from an xsl:attribute or from those in the opening element tag can not be distinguished. See the failing examples below: <elem3> <xsl:attribute name="pre1:nattr" xmlns:pre1="uri1">value1</xsl:attribute> <xsl:attribute name="pre1:nattr" xmlns:pre1="uri2">value1</xsl:attribute> </elem3> is serialized as: <elem3 xmlns:pre1="uri2" pre1:nattr="value1"/> this is wrong because the URI's of the attributes are different ("uri1" and "uri2") but the serializer identifies attributes by prefix:localName and both xsl:attribute elements seem to be setting the same attribute (wrong!). This: <elem4> <xsl:attribute name="pre1:nattr" xmlns:pre1="uri1">value1</xsl:attribute> <xsl:attribute name="pre2:nattr" xmlns:pre2="uri1">value1</xsl:attribute> </elem4> is serialized as: <elem4 xmlns:pre1="uri1" pre1:nattr="value1" xmlns:pre2="uri1" pre2:nattr="value1"/> this is wrong because although the prefices differ the URI's are the same so there should only be one attribute when serialized. <elem5> <xsl:attribute name="pre1:nattr" xmlns:pre1="uri1">value1</xsl:attribute> <xsl:attribute name="pre1:nattr" xmlns:pre1="uri2">value2</xsl:attribute> </elem5> is serialized as: <elem5 xmlns:pre1="uri2" pre1:nattr="value2"/> this is wrong because there should be two attributes when serialized (different URIs) <elem9 pre1:otherattr="other" pre1:nattr="value1" xmlns:pre1="uri1"> <xsl:attribute name="pre1:nattr" xmlns:pre1="uri2">value2</xsl:attribute> </elem9> is serialized as: <elem9 xmlns:pre1="uri2" pre1:nattr="value2" pre1:otherattr="other"/> this is wrong because the URI associated with "otherattr" is no longer "uri1" as it should be. <elem11 pre1:nattr="value1" xmlns:pre1="uri1"> <xsl:attribute name="pre2:nattr" xmlns:pre2="uri1">value2</xsl:attribute> </elem11> is serialized as: <elem11 xmlns:pre1="uri1" pre1:nattr="value1" xmlns:pre2="uri1" pre2:nattr="value2"> this is wrong because both attributes have the same URI ("uri1") and localName so there should only be one attribute when serialized. Conclusion: There are multiple problems with processing xsl:attribute elements. Part of the problem is in the serializer, part of the problem is that there is no internal API to tell the serializer that the attributes (names, values, prefix/uri mapping is due to an xsl:attribute). Some changes will be needed in XSLTC too. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
