RE: [xml-dev] SQL instead of XQuery [offtopic]

[noah_mendelsohn@us.ibm.com]

Michael Kay writes:

> (b) where the purpose of the database is to record events and 
> the events are
> captured by documents - for example safety inspection reports 
> or insurance
> claims. In this situation a database of documents is exactly 
> what you need.

Yes, indeed, but data and document applications are not always separate. 
The example I like to use is of insurance companies.  A list of policy 
holders no doubt fits very well into a relational model, and SQL is great 
for querying and updating it.  For each policy holder there is likely to 
be one or more insurance policy documents, and indeed information like the 
customer ID, policy number, customer's name and address etc. is likely 
shared or linked between the documents and the policy holder list.  Quite 
possibly the policy documents are encoded as some kind of smart template, 
so that a join in a language like XQuery can automatically create the 
policy documents tailored for each customer.  Indeed, there may be logic 
in the template or that XQuery along the lines of:  for any policy in 
excess of $1m, include paragraph 2 on limitations of liability.

The point is that what makes XML so valuable is not just that it can do 
documents, but that it can do these combined document/data applications. 
The xsd:decimal type you use in Schema can be applied to both the amount 
of coverage in the list of policy holders and to the corresponding number 
in the policy document.  You can query for all policy documents in which 
the zip code of the document matches the location of responsibility for 
some the insurance agents in your (data-style) agent list.  It's the 
combination of data and documents in a uniform model that's powerful. 

Of course, there are tradeoffs in all of this.  The JSON community is very 
happy to point out that the mechanisms of XSD and its syntax are 
inconvenient overkill when all you need to pass around are some data-style 
lists of fields, types, values.  They're right about that.  As has been 
eloquently stated on this list, SQL and relational are cleaner (not to say 
having decades of deployment and training investment) when all you need is 
more or less regular data, or things that decompose well into tables. 

I don't have the statistic handy, but many people make the claim that a 
very large fraction of the world's interesting information is stored on 
computers in document style.  Law firms store lists of customers in 
relational (probably), but the contracts, legal decisions, etc. are all 
documents.  In the heydey of relational-only, tables and queries were 
first class, but report writing and document management were sort of an 
add on without a lot of deep architecture and integration.  Now with XML 
we have a system that, however imperfect, can integrate not just the 
managment of data, but the management of the documents created from that 
data, as well as other related documents.  That's a very big deal IMO.

(BTW: Lotus Notes grew up more or less contemporaneously with relational.  
It was one of the first systems to unify data and documents in this style. 
 It's not as open as XML and doesn't aspire to Web scale, and it happens 
to use a flat rather than hierarchical internal model, but otherwise it's 
quite architecturally similar to XML.  Not speaking officially for IBM, I 
believe it has well over 100,000,000 users, depending on how you count.) I 
mention this because Notes was one of the systems that showed that there 
was a real need for something in addition to relational, even as 
relational was growing in popularity.)

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------