Re: [xsl] document() function.

Subject: Re: [xsl] document() function.
From: David Carlisle <davidc@xxxxxxxxx>
Date: Tue, 20 May 2003 09:53:02 +0100
  The xslt working group on W3C appear to be on their way to replacing
  the document() function with doc() which has only the base functionality
  of document()

Dave, as is well known I'm not the world's greatest fan of Xpath2 but 
I believe that you are inventing problems here were there are not really
any (or at least there are other battles that are probably more
important to fight).

Despite the quote that  you gave later, document() isn't being removed or
even deprecated from Xpath, as it is not in Xpath 1 at all.
The only difference is that while some earlier drafts of xpath2
suggested adding it, the current draft has backed off on that and
reverted to the xpath1 situation where document() is a special xslt
addition not part of xpath itself.

I think that if you are looking for reasons for this you should ask why
document() wasn't in xpath1. If it had been then the backwards
compatibility arguments would (I would have guessed) made it almost
certain to be in Xpath2. It is certainly the case that that the two
argument form of document() is not needed in xpath2 as that is only for
resolving relative URI references, and Xpath2 has specific functions
available to combine a base URI and a relative URI, so functions wihich
take URI only need to have one argument form (otherwise they'd all need
to have two arguments forms). Having both doc() and document() in xslt2 is
perhaps a minor blemish, but compared to having 100001 date functions or
pointless casting functions between XSD primitive types on which Xpath
has no functions provided, this doesn't seem anything worth worrying


This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:

 XSL-List info and archive:

Current Thread