RE: [xml-dev] XML vs relational database

[Alessandro Triglia <sandro@mclink.it>]

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: Thursday, August 16, 2007 10:00
> To: Michael Kay
> Cc: 'Sylvain LOISEAU'; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML vs relational database
> 
> Also, I think it's useful to consider separately collections 
> of "well formed" XML, vs. collections known to be valid per 
> some schema. 
> Collections of well formed documents behave as you describe:  
> because they vary a great deal in structure, you generally 
> have to interrogate the structure of each instance if you 
> care, and to a significant degree the structures are self 
> describing.  I think that a SQL table more closely resembles 
> a collection of documents known to be valid per some schema. 
> Depending on how rigid the constraints imposed by the schema 
> are, it may or may not tightly bound the structure of the 
> instances.  Still, it's reasonable to ask:  can a query 
> interrogate the schema, which is analagous I think to 
> querying the structure of SQL tables.  The answer in XML will 
> depend on which schema technologies and query systems you 
> adapt.  I will say that one reason that XML Schema goes to 
> such trouble to formalize not just its transfer syntax but 
> also it's so-called "component model" is to make possible 
> exposing the semantics of the schema to query systems. 
> What's missing, I should say, is a standard XML serialization 
> that's quite ismorphic to those components.  What we have 
> today for a transfer syntax is more analagous to the SQL 
> statements that would define a table, rather than schema 
> table that would describe its columns.  Schema components are 
> analagous to the latter, and are quite carefully set out.  
> There is no standard transfer syntax isomorphic to those 
> components at this time, although nonstandard versions have 
> been put to good use (e.g. the -r switch on XSV).


I think the XML Schema Recommendation would be easier to read and digest if the document had a different structure.  I think Part 1 could even be split into two Parts, or at least have two very distinct sections--one specifying the abstract component model and the validation rules, and the other specifying the mapping from XML schema instances to the component model.  Then you could specify not just one but two such mappings (one more human-friendly for use by schema authors and mainly directed FROM the schema infoset(s) TO the schema components, the other more machine-oriented and inherently bidirectional and producing schema infoset instances that are more isomorphic with the abstract schema components).   I think the current approach addresses two very different levels of concerns within the same specification text (with the respective portions being interleaved in each clause), and so makes the specification harder to read and understand.  For example, I believe the dist!
 inction between a schema and a schema document, or between a complex type and a <complexType>, is not very clear to the average user today, but might be more clear if those two things were defined in distinct parts of the text.

Alessandro Triglia
OSS Nokalva