[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Identity of Documents Puzzle

Subject: Re: Identity of Documents Puzzle
From: "W. Eliot Kimber" <eliot@xxxxxxxxxx>
Date: Mon, 09 Dec 2002 07:47:02 -0500
the absolute uri
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



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.