> Updating existing ML Server XQuery code to XQuery 1.0 syntax won't be a
> trivial operation, but I agree that the less divergence from current
> standard the better. Although it will probably always be the case that
> any XQuery code that does complex jobs will need to use proprietary
> extensions, and there won't always be a one-to-one mapping between one
> implementation's and anothers.
Yeah, the fact that I want to do things beyond what XQuery seems capable
of at 1.0 is annoying, especially since both vendors have implemented
a lot of the same sorts of things, just using different signatures!
At this point I'm thinking what I'll try to do is write wrapper functions
which map to the same outward signature, and then have installed bases
where one set of libraries has some Mark Logic specific underlying
modules and the other set of libraries has some Saxon specific libraries.
I've not yet delved too deeply into the quirks of Library Module handling
in XQuery, so I hope I don't get my hopes stomped flat when I try this. :)
Re: the issue of upgrading existing Markogic Server XQuery code to the
offical spec when it is released and supported by Mark Logic: I wonder
how hard it would be to do the 'upgrade' in an automated(ish) fashion
using a pipeline of XQueryX transformations.
Old XQuery -> old XQueryX -> XSLT -> new XQueryX -> New XQuery
Where, perhaps, the transform might be a bit easier to write when
mapping from one XML syntax to another, closely related, syntax.
Of course, that assumes anyone has written parsers to load the
old syntax and to dump the latest XQueryX into 'human' form.[1]
> I find that for our workflow, working with long docu-centric XML files,
> it works best to use Saxon queries with files on a local filesystem
> while lots of changes are being made to them, then switch over to ML
> Server code once the files are fairly stable (because the time it takes
That's interesting, I would have assumed the opposite flow -- doing
the maintenance and heavy lifting in MarkLogic Server, and then
perhaps 'exporting' it to the filesystem for some in-memory Saxon
based XQuery engine.
Jim
[1] A Google search reveals at least one page which seems to indicate
the underlying blocks for such a pipeline are available:
http://monet.nag.co.uk/xq2xml//index.html
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson [EMAIL PROTECTED]
Stanford University HighWire Press http://highwire.stanford.edu/
+1 650 7237294 (Work) +1 650 7259335 (Fax)
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
