RE: document() function.

> 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() 
> http://www.w3.org/TR/xquery-operators/#func-doc
>

No, there are no plans to remove or deprecate the document() function. 
> 
> You could see this to be the first stage of a deprecation of
> fn:document() in XPath. First, we provide a simpler function. 
> In a later version, fn:document() may be removed.

You can see it as anything you like. You might be able to predict the
future, I can't.
> 
> At least that's how I personally see the reason for keeping 
> both in XPath. 
> 
> If you need other than the simpler functionality of doc() and 
> don't want to change your stylesheets, please let them know.
> 

I can't quite see why we need 100 public comments telling us to keep the
document() function when we have no intention of removing it.

There are three things that the document() function provides which
aren't provided in the doc() function:

(a) the ability to specify how a relative URI is resolved. When using
the new doc() function, you can control this yourself by calling the new
resolve-uri() function, which gives you more capability, not less.

(b) the ability to retrieve multiple documents in a single call. This
can easily be achieved, again with greater flexibility, by using doc()
within a "for" expression.

(c) the ability to handle fragment identifiers based on the media type
of the resource. this capability in the document() function has always
been implementation-defined, and as far as I am aware it has rarely been
implemented and even more rarely used.

But the reason for retaining document() isn't because it provides
functionality that isn't available from the doc() function, it's because
millions of stylesheets are using it.

Michael Kay


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list