RE: V.next: Use case: XQuery inputs ...

> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Thursday, February 02, 2012 1:17 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: Re: V.next: Use case: XQuery inputs ...
> 
> "vojtech.toman@emc.com" <vojtech.toman@emc.com> writes:
> > Btw, the support for application/xquery in p:xquery is one of the
> > things that I am going to talk about at XML Prague. But as Alex says,
> > it depends on XProc supporting multiple media types.
> 
> Support for media types doesn't sound like its necessarily a big item,
> can you outline how you do it? (Or should I just wait until next
> weekend :-)

It is based on shimming. It is no rocket science: Steps declare what media types they expect on their input ports, and what media types they produce on the output ports. If data of media type A arrives on an input port that accepts media type B, the processor converts the data from A to B (if it knows how to do that).

In the case of p:xquery, the "query" input port is declared as accepting application/xml (for backward compatibility with the XProc specification). When data of media type application/xquery arrives on the "query" input port, the processor converts it to application/xml by wrapping it in a c:query wrapper (the actual implementation of this can, obviously, skip the wrapping and pass the raw query string to the p:xquery step directly).

You could also imagine an alternative scheme where the "query" input would be declared as accepting application/xquery and if an XML document arrived on the "query" port, the processor would convert it to XQuery by taking the string value of the document element.

I should note that shimming is only part of my paper. The more interesting part, I think, are the implications of this on XPath in XProc.

Regards,
Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech

Received on Thursday, 2 February 2012 12:45:08 UTC