[xquery-talk] File Systems & XQuery

Frans Englich frans.englich at telia.com
Wed Feb 7 17:05:54 PST 2007

On Wednesday 07 February 2007 16:24, Florent Georges wrote:
> Frans Englich wrote:

> > $fs/directory[@name =
> "home"]/directory[@name="frans"]/directory[@name="xmlExamples"]//*[@mimeTyp
>e eq 'application/xml']
>   I definitely prefer the Saxon way.
> > Is this idea overkill?
>   Maybe.  The Saxon default collection URI resolver is really great to
> use.  The question is: is there real use cases that legitimates all
> that?

One of those questions that are always sensible to ask.

Yes, I think that the general idea of file system inspection is useful. For 
example, I think you can build quite interesting -- and useful -- systems by 
combining quick document loading, clever document caching, and file system 
inspection. Perhaps Mike can provide examples, who actually has users using 
such a mechanism. But I agree that it so far hasn't been demonstrated why 
this would be justified in a broader perspective.

I think it's a good idea to get the different usage scenarios separated:

* When you know the URI at compile time and wants to iterate the files in that 
folder, or similar. For this case specifying the URI with a URI makes sense, 
and is why Saxon's approach is appealing here, and why using a namespace(and 
hence prefix in paths, as pointed out by John) and XPath-paths appear 
annoying. This is why a URI should be specified for whole paths, instead of 
things like "directory[@name="frans"]/..".

* When you need to query/select files. For this I think the XPath syntax is 
acceptable and provides the necessary functionality.

So, when using an extension function, it would instead look like this:

file-system("file:///home/frans/")/*[@name eq 'myFile.xml']

URIs for URIs, and XPath for querying. Sounds proper, at least.

Like this, the use of a namespace isn't very cumbersome. I'm still in favour 
of a namespace, such that it can be combined with other vocabularies, such as 
embedding it in other documents.


More information about the talk mailing list