[ http://nagoya.apache.org/jira/browse/XALANJ-1886?page=history ]
Henry Zongaro updated XALANJ-1886:
----------------------------------
Assign To: (was: Xalan Developers Mailing List)
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.
was:
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.
Environment:
Operating System: Other
Platform: Other
was:
Operating System: Other
Platform: Other
Priority: Blocker
Bugzilla Id: (was: 29488)
Xalan-keywords: PatchAvailable
> Multiple problems with collecting xsl:attributes with over-ridden values and
> prefix/URI maps
> --------------------------------------------------------------------------------------------
>
> Key: XALANJ-1886
> URL: http://nagoya.apache.org/jira/browse/XALANJ-1886
> Project: XalanJ2
> Type: Bug
> Components: Serialization
> Versions: CurrentCVS
> Environment: Operating System: Other
> Platform: Other
> Reporter: Brian Minchau
> Priority: Blocker
> Attachments: patch2.txt
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
