Characterizing XQuery implementations: Categories and key features
Before I start this review let me link to Uche Oqbuji’s blog at O’Reilly for Day 2. I imagine that people are coming here looking for insider information about Extreme…and good commentary. I am not the correct place for that…but I am learning much from Uche’s description of the sessions I am in…while I am sitting behind him watching him type the comments to his blog. Very surreal. Anyway, go to him for more detailed and coherent reviews of the presentations. Why people aren’t tagging their blog entries for technorati I have no idea.
Onto the actual commentary…
Liam is a character. He is standing in the front of the room without a working laptop, in a sun and moon vest, no shoes, and a floppy wizard’s hat. And he just started chatting about XQuery.
There are at least 50 XQuery implementations….and they are all different from each other. He is giving them the benefit of the doubt and imagines that they all work for something…so he divides them into these categories…and he is also going to name names. As examples, not as product suggestions.
Things you need to know about an implementation:
- Business model – will the company be there tomorrow
- Access – how do you get at the XQuery? Can you even get at it at all?
- primary Purpose – what are you going to use it for…what was it designed for?
- Storage Strategy – where do they put the XML?
- Supported Closed Source
- Unsupported Closed Source – Avoid these people
- Open source with a commercial version – Saxon, Qizx
- Open source with informal support – Galax
- Research or personal projects
- Demo version – not the same as open source or free
Moving between implementations is facilitated by a standard language. Choice of vendor is less important if you avoid using propriety features or extensions.
Conformance is what lets you migrate. If it doesn’t conform to the standard (or have a formal conformance statement) be careful.
Language migration is doable if you make the functions as language neutral as possible.
command line – Galax, Saxon, Qizx
Servlet – Qizx
embedded in another language – SQL, DB2, Oracle, MSSQL
API/Library – BSD dbxml
Web server – Sedna, MarkLogic, DataDirect
GUI – oXygen, StylusStudio
large cache – markLogix, Db2
Streaming – BEA, AquaLogic (mobile phone – “I only want a mobile phone for an alarm clock, a phone, and throwing at people”)
Database quesry language (Sherlock)
middle ware (DataDirect)
Storage Strategy :
On top of SQL – XQuark
Alongside SQL – DB2, Oracle, MonetDB/XQuery
XML-Native DB – eXist, markLogic
other XDM – Sherlock (constructs instances of the data model)
Files – Saxon (not all XQuery systems can use files…so it depends on how you want to store the XML)
If you write native functions hide them in a module that you can know to reimplement.
Tommie Usdin: I have heard it said that XQuery is XSLT in fancy dress. Liam: The biggest difference from my perspective is the aim of the products. XQuery is aimed at extracting a small amount from a large amount of data.
Michael Kay: The differences between the products is much different than the differences between the languages.
What’s the state of the features in the implementations? All the serious implementations are moving toward required features but the optional features are what they seem to be competing on.