[xquery-talk] File Systems & XQuery

Peter pc.subscriptions at gmail.com
Wed Feb 7 16:25:26 PST 2007


Perhaps 

http://www.alphaworks.ibm.com/tech/virtualxml

How does it work?
With the new Virtual XML Garden release, users can write scripts in XPath
and XQuery that mix and match data retrieved from virtual XML views in order
to create derived views or "XML mash-ups" with data from a wide variety of
data sources:
....
    * entire file systems, mapping the directory structure to a virtual XML
document structure (which can, in turn, be used as data sources and
"inlined" as XML)
....


> -----Original Message-----
> From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
> Of Michael Kay
> Sent: Wednesday, February 07, 2007 4:14 PM
> To: 'Frans Englich'; talk at x-query.com
> Subject: RE: [xquery-talk] File Systems & XQuery
> 
> Kristoffer Rose of IBM Research has demonstrated this kind of idea, but I
> can't find a reference at the moment.
> 
> Michael Kay
> http://www.saxonica.com/
> 
> 
> 
> > -----Original Message-----
> > From: talk-bounces at x-query.com
> > [mailto:talk-bounces at x-query.com] On Behalf Of Frans Englich
> > Sent: 07 February 2007 14:15
> > To: talk at x-query.com
> > Subject: [xquery-talk] File Systems & XQuery
> >
> >
> > 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
> 
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk



More information about the talk mailing list