Tool development: by Perl-wrapped XQuery

[Pavel Minaev]

On Fri, Sep 4, 2009 at 5:03 AM, David A. Lee<http://x-query.com/mailman/listinfo/talk> wrote:
> But equally important, IMHO,  is to be able to "glue" the data from one
> module to another efficiently.  That needs common in-memory formats.
> And a way in the language to make calling these modules and passing data
> to/from them easy in a way thats 'natural' for that language.
> That may mean, for example, that the language runtime define a standard XML
> in-memory representation and every module can use it natively.
> So that you can have say variables of XML Documents and not have to
> transform them to each module's internal representation (rebuild the
> document).

This is a very important point. I am mostly dealing with XSLT, XQuery,
and the rest of the stack from .NET perspective. There, we actually do
have a standard representation of XML - IXPathNavigable factory
interface and the associated XPathNavigator cursor class. In fact, it
is specifically designed in a way that makes a straightforward mapping
to XDM possible (to quote MSDN: "The XPathNavigator class in the
System.Xml.XPath namespace is an abstract class which defines a cursor
model for navigating and editing XML information items as instances of
the XQuery 1.0 and XPath 2.0 Data Model."). All .NET XML APIs provide
support for those interfaces one way or another - all in-memory XML
tree representations (and there are three of them in the standard
library) can be treated as IXPathNavigable, .NET stock XSLT 1.0
implementation takes an IXPathNavigable as a source, stock XML Schema
validator also works with it, and so on. The interface is also simple
enough that I can take virtually any data source (e.g., an object
graph), easily expose it as an XDM instance, and feed that to any
XML-processing pipeline (usually XSLT) as an input, with no need to
copy data back and forth.

So, all stock components integrate really well together, with no
representation mismatch (and yet representation itself being nicely
abstracted away), but they are dated (XSLT 1.0... 'nuff said). And
third-party components often don't integrate that well. For example,
there's no XSLT 2.0 implementation for .NET that works directly over
IXPathNavigable input trees (without making an extra copy), or that
provides output in a form for which an XPathNavigator can be
immediately provided without copies. And the first and only XQuery
implementation which supports all of the above that I'm aware of is
the recently released XQSharp.