[xquery-talk] File Systems & XQuery

[John Snelson]

Hi Frans,

This is a really interesting idea, which I think could be very useful. 
Personally I like the first syntax more - after all this isn't about 
good document design, it's about ease of use.

You would need to easily be able to fetch an XML document using the 
syntax, so you should probably add an attribute that returns the URL to 
the file:

doc(collection("http://fs-xquery.fs.net/")/home/frans/xmlExamples/foo.xml/@url)

The trouble with namespacing the document is you would have to use 
prefixes in all your paths, which would make it harder to use - or at 
least less pretty. Is there a strong argument to use a namespace?

John

Frans Englich wrote:
> Hello all,
> 
> When writing XML applications, one currently needs glue and helper utilities 
> to compensate for missing parts, or tie steps together. This could be piping 
> the result of a schema validation to a transformation step, or determining 
> what files to open in an XQuery query. XProc[1] is one attempt to solve these 
> kind of problems.
> 
> For navigating and inspecting the file system from XQuery, one approach is 
> that of Saxon's[2], where a mini-homebrewn query is passed as an URI to 
> fn:collection().
> 
> I see some drawbacks with that approach:
> 
> * It invents a new "language", instead of using XPath, and is therefore 
> limited, comparatively.
> * The result is not expressed with the XPath Data Model and therefore one 
> cannot use it as such; for example, transform it with a stylesheet.
> 
> I'm here venting the idea of another approach to inspecting the file system:
> 
> An absolute URI would be passed to fn:collection(). It would always be the 
> same regardless of what files being queried, just like a namespace.  
> fn:collection() would in turn return a node that represents the root of the 
> file system. In the case of MS Windows platforms(and other platforms), the 
> root node would be virtual, containing drives as children.
> 
> The returned node would mirror the file system, where each node representing a 
> file would have attributes such as mimeType, fileSize, absolutePath, and so 
> forth. Since it's a plain XDM node, the user has strong expressiveness with 
> XPath.
> 
> There are certain design issues with this, such as how the XML format would 
> be. This, for instance, is very friendly from a query-writing perspective:
> 
> declare variable $fs := fn:collection("http://fs-xquery.fs.net/");
> $fs/home/frans/xmlExamples//*[@mimeType eq 'application/xml']
> 
> However, since this use dynamic elements, it's tricky to express with a Schema 
> and considered by many as bad design(which I would agree with, but I do think 
> it makes query writing elegant).
> 
> The alternative is rather messy for query writing:
> 
> $fs/directory[@name = 
> "home"]/directory[@name="frans"]/directory[@name="xmlExamples"]//*[@mimeType 
> eq 'application/xml']
> 
> Either alternative is equally horribly, but in their own way. Is there a third 
> alternative? Can they be combined? Is any alternative acceptable?
> 
> Many parts of this would be implementation defined(such as mime type detection 
> and pretty much everything else). One issue is node stability, especially 
> when put in relation to changes to the file system.
> 
> Such a "mini"-spec could have two levels of conformance: for statically typed 
> and not. For typed implementations, fn:collection's return value would have a 
> more specific return type, instead of "element()".
> 
> The XML format would be in a namespace. Should that namespace equal the 
> collection URI? That's simple, but maybe there's some issue that I not see.
> 
> Is this idea overkill? Useful? Doable? If it's possible, I think it would be 
> an elegant use of the XPath Data Model's abstraction to the underlying 
> representation, and an interoperable mechanism to query the filesystem. I 
> believe it would render many small scripts and Makefiles redundant.
> 
> If it's possible, I consider writing up a draft for this, but some initial 
> input would be appreciated!
> 
> 
> 		Frans
> 
> 1.
> http://www.w3.org/TR/xproc/
> 
> 2.
> http://www.saxonica.com/documentation/sourcedocs/collections.html
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk