[Bug 1860] [XSLT] Uses cases for document() functions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1860





------- Additional Comments From mike@saxonica.com  2005-08-19 09:48 -------
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

Received on Friday, 19 August 2005 09:48:06 UTC