[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Identity of Documents Puzzle

---

---

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@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of W. Eliot
Kimber
Sent: segunda-feira, 9 de Dezembro de 2002 12:47
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxx
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

---