I posted this on my blog, and got a lot of responses saying that it
would be an extremely good thing to have, particularly for XSLT
processing rather than XQuery itself. I was wondering if these
functions could be considered for inclusion in the XPath function set.
As they're functions, they don't represent a change to the language
syntax, and they also could be essentially stubbed out for
implementations that don't support them.
-----------------------------------------------------------------------
XQuery and XPath operate against the notion of a dynamic context, where
the concepts of current collection, and document set are knowns, yet
there are no functions available for exposing those variables. As a
person who pretty much lives XML database technology, I find that
information incredibly important from an implementation standpoint, if
only to minimize reliance on APIs such as the XML:DB API in order
perform repository discovery.
Therefore I propose that the following functions be added that expose
additional aspects of the dynamic context:
fn:default-collection() as xs:anyURI
Returns a URI to the default Collection.
fn:child-collections(xs:anyURI) as xs:anyURI*
Returns a sequence of URIs to for the specified URI. Return an empty
sequence if there are none, or an error if the underlying store does not
support this functionality.
fn:child-collections() as xs:anyURI*
Same as the child-collections(xs:anyURI) form, but executed against the
default collection.
fn:collection-documents(xs:anyURI) as xs:anyURI*
Returns a sequence of URIs identifying the document resources that are
associated with the specified collection URI. Return an empty sequence
if there are none, or an error if the underlying store does not support
this functionality.
fn:collection-documents() as xs:anyURI*
Same as the collection-documents(xs:anyURI) form, but executed against
the default collection.
--
Tom Bradford - Virtuoso Technology Evangelist
OpenLink Software: http://www.openlinksw.com/
Personal Web Log: http://www.tbradford.org/