Thursday, August 27, 2009

xmlsh extension functions in xpath/xquery/xslt

Thanks to Kurt Cagle for the suggestion, I've implemented extension functions in xpath/xquery/xslt and the builtin <[ ... ]> notation.

The one function is "eval". This allows you to call into xmlsh from within any xpath expression and return the result (stdout) of the command back.
Right now I have set it so you have to manually declare the namespace, saxon style.
Examples:


declare namespace xmlsh=java:org.xmlsh.xpath.XPathFunctions
xecho <[ xmlsh:eval("xecho $*" , ("foo" , <bar/>, 1 ) ) ]>
xquery -n 'xmlsh:eval("xls")'
xpath -n 'xmlsh:eval("xls $*" , "*.xml")'
var=<[ xmlsh:eval("xls") ]>



I think this is an extremely useful feature (thanks to Kurt for suggesting it !), and I want to make it easier to use by not requiring the "declare namespace". But, I don't want to impose magic namespaces into code that isnt expecting it. Also doing this globally results in a namespace declaration in the output (which is being stripped out by the serialization process but is still there under the hood).

To solve the first problem, I'm thinking of building in the 'declare namespace' part into the <[ ... ]> syntax only and leaving it up to the user to decide to import the extension functions themselves for explicit calls to xquery/xpath/xslt.

I'm not sure how to solve the second problem, although it is largely an invisible one. I was reading on the saxon docs and the suggestion was to do the namespace declaration in the preamble of xquery itself rather then externally to avoid extraneous namespace declarations resulting in the output. Thats what I'd do for the <[ ...]> but maybe I should leave it up to the user to do that their own way for an explicit call to xquery/xslt/xpath.

As for the namespace prefix ... there's a convention of using "ex" for extension functions so maybe I should pick "xmlshex" although thats getting long, or just "ex" ... opinions welcome !


1 comment:

  1. This is now in 0.1.0.0 ...
    I've added to svn (but not yet in release) support for the xpath context inside eval exposed as the stdin. This allows an intersting "pipeline like" expression syntax entirely within xpath.
    Example
    /foo/bar/xmlsh:eval("xslt -f stylesheet")/spam

    which would be the equivalent of

    xpath /foo/bar | xslt -f stylesheet | xpath /spam

    but run entirely within xpath/xquery/xsl

    ReplyDelete

Due to comment spam, moderation is turned on. I will approve all non-spam comments.