Characterizing XQuery implementations: Categories and key features

Liam Quin, World Wide Web Consortium

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?

Business Model:

  • 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.

Access (examples):

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)

Web applications

General purpose

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)

Common Traps:

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.

Explore posts in the same categories: extrememarkup, extrememarkup07

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: