Re: [xml-dev] Modern talking

["Ghislain Fourny" <gfourny@inf.ethz.ch>]

Hi,

> But if you're going to aim for the skies in terms of a unified information model, then it has to be something RDF-like rather than something XML-like. XML is just too littered with arbitrary quirks. I've always felt that XQuery was too closely tied to XML to have aspirations to become something more universal. Sure, many of the ideas in XQuery are great, and independent of the model, but some of the features (such as element constructors, or the magic 19 primitive data types) are just too tied in to the particulars of XML. 

I second the essence of what you say, Mike: many ideas of XQuery are great and independent of the model. I have a slightly more optimistic view on this, though (XQuery being tied with XML).

What gives the illusion that XQuery is tied with XML, in my view, is that, because of the complexity of XML, the part of XQuery that ties it with XML uses a significant part of the room of the specification. Of course, element constructors are tied to XML but this is because they construct an XML element node. If one drops it all (e.g., as in JSONiq), the tie is gone. Rather than considering XQuery tied to XML, I would tend to say that the XML data model is tied with its syntax -- unlike RDF, which has several syntaxes.

I would argue that the primitive data types as not so tied to XML. If one looks at the list of the 19 primitive types from the XML Schema specification, only the last two -- maybe the last three -- really are. The others make a lot of sense in non-XML environments as well. The broad categories (string, boolean, numbers, dates and times, durations, binary, ...) are encountered in most databases, even relational.

        3.2.1 string
        3.2.2 boolean
        3.2.3 decimal
        3.2.4 float
        3.2.5 double
        3.2.6 duration
        3.2.7 dateTime
        3.2.8 time
        3.2.9 date
        3.2.10 gYearMonth
        3.2.11 gYear
        3.2.12 gMonthDay
        3.2.13 gDay
        3.2.14 gMonth
        3.2.15 hexBinary
        3.2.16 base64Binary
        3.2.17 anyURI
        3.2.18 QName
        3.2.19 NOTATION

Regarding RDF: One can express trees as graphs and convert XML to RDF, but I am not sure that this is the best idea for all use cases. Trees have no cycle, and this has an impact on how they are queried, and most importantly, on performance. My general feeling is that storing trees in RDF would be a little bit as if chemists were working with quarks: there is always an appropriate level of abstraction.

Just my 2 cents!

Kind regards,
Ghislain