[
https://issues.apache.org/jira/browse/XALANJ-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734912#comment-17734912
]
Joe Kesselman edited comment on XALANJ-2474 at 6/20/23 2:02 AM:
----------------------------------------------------------------
Check their usage of generate-ID(). True, XPath says
{code:java}
generate-id(document("foo.xml"))=generate-id(document("foo.xml")){code}
But that is only promised if the two URIs are IDENTICAL STRINGS. After much
argument, the W3C concluded that there is no general way to test that two
relative URIs will evaluate to the same absolute URI, and thus equality
comparison of URIs operates strictly on a string-to-string basis. If the main
document's URI is being absolutized and document()'s isn't, or vice versa, then
different IDs may be generated. (Or may not.) This function is reliable only
for nodes known to be within the same document tree.
As a test, I annotated the *findmatch* template, where one of the
*generate-id()* calls occurs, with
{code:java}
<xsl:message terminate="no">generate-ID(/)=<xsl:value-of
select="generate-id(/)"/></xsl:message>
<xsl:message terminate="no">generate-ID(document($global.result))=<xsl:value-of
select="generate-id(document($global.result))"/></xsl:message>
{code}
Sure enough, the output consistently reports two different IDs for the
stylesheet input's document node and that returned by the multiple *document()*
calls, respectively *N10000* and {*}N20000{*}, as permitted (and arguably
desirable) if their URIs are not completely identical.
I'm not sure yet whether that's the cause of this problem – whether they're
assuming that the two documents are actually the same tree – but it's exactly
the kind of edge case that we were chasing down and fixing around that time,
and it's quite possible that previously we were not correctly distinguishing
two different URI strings that had "apparently equivalent" meaning.
If so, then the question may be one of base behaviors – whether the URI as
entered, or the URI as resolved, shall be used by Xalan as the document's
identity. The fact that both were entered as the same relative URI is simply
not enough to imply that.
I know we made some explicit decisions on this issue. Any surviving record of
that discussion would be in the deep archives of xalan-dev.
*CAVEAT: I have not actually confirmed that this is the place where their
stylesheet is failing.* I haven't done a deep analysis of how they are caching
and checking node IDs and whether they ever attempt to use an ID from one
document to reference the other. But it's one likely place to look for a
behavior change between Xalan releases that could affect this stylesheet.
was (Author: JIRAUSER285361):
Check their usage of generate-ID(). True, XPath says
{code:java}
generate-id(document("foo.xml"))=generate-id(document("foo.xml")){code}
But that is only promised if the two URIs are IDENTICAL STRINGS. After much
argument, the W3C concluded that there is no general way to test that two
relative URIs will evaluate to the same absolute URI, and thus equality
comparison of URIs operates strictly on a string-to-string basis. If the main
document's URI is being absolutized and document()'s isn't, or vice versa, then
different IDs may be generated. (Or may not.) This function is reliable only
for nodes known to be within the same document tree.
As a test, I annotated the *findmatch* template, where one of the
*generate-id()* calls occurs, with
{code:java}
<xsl:message terminate="no">generate-ID(/)=<xsl:value-of
select="generate-id(/)"/></xsl:message>
<xsl:message terminate="no">generate-ID(document($global.result))=<xsl:value-of
select="generate-id(document($global.result))"/></xsl:message>
{code}
Sure enough, the output reports two different IDs for the input's document node
and that returned by the multiple *document()* calls, respectively *N10000* and
{*}N20000{*}, as permitted if their URIs are not completely identical.
I'm not sure yet whether that's the cause of their problem – whether they're
assuming that the two documents are actually the same tree – but it's exactly
the kind of edge case that we were chasing down and fixing around that time,
and it's quite possible that previously we were not correctly distinguishing
two different URI strings that had "apparently equivalent" meaning.
If so, then the question may be one of base behaviors – whether the URI as
entered, or the URI as resolved, shall be used by Xalan as the document's
identity. The fact that both were entered as the same relative URI is simply
not enough to imply that.
I know we made some explicit decisions on this issue. Any surviving record of
that discussion would be in the deep archives of xalan-dev.
*CAVEAT: I have not actually confirmed that this is the place where their
stylesheet is failing.* I haven't done a deep analysis of how they are caching
and checking node IDs and whether they ever attempt to use an ID from one
document to reference the other. But it's one likely place to look for a
behavior change between Xalan releases that could affect this stylesheet.
> document() function returns different values with xalan version 2.7.1. and
> 2.6.0.
> ---------------------------------------------------------------------------------
>
> Key: XALANJ-2474
> URL: https://issues.apache.org/jira/browse/XALANJ-2474
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Affects Versions: 2.7.1
> Environment: Windows, using command line transform of xalan.
> Reporter: pavankumar
> Priority: Blocker
> Attachments: input.xml, transform.xslt
>
>
> xslt document() function returns duplicate and improper values with 2.7.1.
> where as the same code works with 2.6.0.
> Info : document and evaluate functions are used in xslt and there were other
> slightly inconsistent behaviour also for 2 versions in terms of syntax and
> all. and xlink:href is getting nil values in 2.7.1
> document result contained by path variable line 93 - transform.xsl is the one
> causing problem. and and when printed, it outputs different values with
> different versions.
> Executed using xalan CLI
> C:\>java org.apache.xalan.xslt.Process -IN "C:\input.xml" -XSL
> "C:\transform.xslt" -OUT new.html -PARAM global.result input.xml
> attaching the files.transform.xslt and input.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
