Not quite, you could made a web page compare its Server Variable
"PATH_TRANSLATED" to see if it is the same or not. But that whould
depend on the system you use (IIS or another) setting this variable.
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of W.
Eliot
Kimber
Sent: segunda-feira, 9 de Dezembro de 2002 12:47
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Identity of Documents Puzzle
Michael Kay wrote:
First point is, that "the same file" is not a concept that any XSLT
processor will recognize. The closest you can get it "the same URI".
No XSLT processor is going to recognize that
http://saxon.sf.net/index.html is the same file as
http://saxon.sourceforge.net/index.html
Yes, which is the fundamental problem. But this problem is not limited
to XSLT--it's a fundamental problem with the Web's addressing
architecture. I don't fault XSLT for not stepping up to solving it.
Nevertheless, there is a general requirement for the ability to
establish storage object identity that I must satisfy in order to
implement certain business processes (e.g., my use of XInclude to do
managable re-use of compound document components that involve complex
systems of hyperlinks).
The rule that two calls on document() supplying the same absolute URI
will return the same document node is defined in the XSLT spec, and
most processors are likely to implement it using some kind of mapping
table from URIs to nodes. In Saxon this is referred to as the
"document pool".
Saxon doesn't include the initial input document in the document pool.
There is no requirement in the XSLT spec that says it should, though I
think there is also no requirement that prevents it, in those cases
where the absolute URI is known. If you want, you can add it yourself
using ((Controller)transformer).getDocumentPool().add(x,y). You could
also intercept the call on document() by means of a user-written
URIResolver, which would be a more portable solution.
Cool, I'll explore this approach.
I was able to get a solution using the 6.5.2 code base by implementing
an "absolute-uri" function that allows me to normalize all the URIs
being used to consistent strings. This will work for at least the
Windows case (because Windows doesn't have symbolic links) but wouldn't
necessarily work for *nx as the same inode could have many different
equivalent filenames (but is probably sufficient for most practical
applications where documents are closely managed).
Cheers,
E.
--
W. Eliot Kimber, eliot(_at_)isogen(_dot_)com
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list