[XALANJ-1886] Multiple problems with collecting xsl:attributes with over-ridden values and prefix/URI maps

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.7.1
• Fix Version/s: 2.7
• Component/s: Serialization
• Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.)
• Environment: Operating System: Other; Platform: Other
• Xalan info: PatchAvailable
• Fix priority: fp1
• Assignee: Brian Minchau
• Reporter: Brian Minchau
• Reviewer: Morris Kwan
• Created: 10/Jun/04 07:04
• Updated: 19/Aug/05 11:44
• Resolved: 18/Feb/05 13:59

Description

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.