I'm surprised by your comment, since there is very little that is new in the
document() function compared with XSLT 1.0. The specification has been
generalized a little: 

(a) in XSLT 1.0 the argument had to be either a node-set or a string, we now
allow other arguments such as a sequence of xs:anyURI values. That's really just
to integrate the new type system cleanly rather than to provide any new
functionality; 

(b) we have changed the way we describe the process of URI dereferencing to make
it clear that what you get back is context-dependent (this reflects the reality
of APIs that allow you to do your own URI derefencing with a user-written
URIResolver).

Our general approach in the specification has been to reduce the amount of
"justification" (that is, explaining why the features are provided, as distinct
from explaining how they work), particularly in relation to features that were
present in XSLT 1.0 and are now widely covered in books and tutorials. Examples
to make the specification clear are in scope; use cases to give users ideas on
how to exploit the features are not.

If this response is acceptable, I'd be grateful if you could close the bug as it
will save scarce Working Group time.

Michael Kay
personal response

Hi Mike,
  Thanks for your response. I have two small doubts about document function, 
and would be grateful if you could clear them for me (after which I shall 
close this bug). 

Now argument of document function can be sequence of xs:anyURI. 

I have following questions:

1) If multiple documents are specified in document(), then would the result be 
the union of node-sets formed by root node of each XML document? Also can the 
arugument of document point to a non-XML resource (for e.g. a text file)?  
  
2) Now since argument of document() can be URIs, then will the XSLT processor 
send some sort of request to the resource over some protocol(like HTTP)?

I'll be grateful for the answers to my doubts..

Regards,
Mukul

The ability to take a sequence of xs:anyURI values (as distinct from a single
URI) is not really an innovation, since XSLT 1.0 allows you to supply a sequence
of nodes: for example in 1.0 you could do document(//@href) to select all the
documents referenced in any @href attribute. The spec says that you get the
results back without duplicates, so if there are two @href attributes with the
same value, you only get one instance of the target document back. The same is
true if you supply a sequence of xs:anyURI values.

The spec has deliberately left it very open what kinds of URIs are accepted
(XSLT 1.0 contained more discussion of the possibilities, but in essence it
still left it implementation-defined.) One might reasonably expect a processor
to retrieve an XML document identified using a file:// or http:// URI, but there
might be environments (e.g. secure environments) in which that doesn't work, for
good reasons. Many XSLT 1.0 processors provide hooks (a "URIResolver") that
allows you to configure the document() function to retrieve non-XML resources
(for example, to get data from a relational database, or to retrieve HTML
dynamically converted into XML), but there's nothing in the spec that says the
processor has to support that.

The formalism used (it's in the XPath spec, referenced indirectly via the doc()
function) is that the processing context contains a mapping from URIs to
document nodes. That's just a rather formal way of saying that there's something
in the environment which takes URIs as input and hands back document nodes in
return, and we regard that something as a black box. 

Michael Kay

Thanks Mike for sharing your thoughts on this subject. But frankly, some of 
your explanation went over my head (as my knowleadge is limited).. I am trying 
to understand some finer points of XSLT 2.0 spec(like this one). Instead of 
wasting WG's valuable time in further discussing the topic, I'll close this bug
(I take the liberty to close it myself). 

I am happy with your reply. Thanks!

Regards,
Mukul