OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Specs are not insane, people are

[ Lists Home | Date Index | Thread Index ]

10/28/02 11:23:01 PM, "Rick Jelliffe" <ricko@allette.com.au> wrote:

>rather are a physical model.  Consequently, most schema languages for
>XML will work best (if one is trying to use them as a logical model) for
>data sets when there is little difference between the logical and the physical.
>?Which kinds of data are these: trivially, heirarchical structures with
>a strong ordering between elements. And, structures which can typically
>be processed efficiently by knowledge of the ancestors and their attributes.

This ties in with what somebody wrote about RDBMSs lacking sufficient performance for chip-design 
applications and the like.  In chip design and general electronic design, the majority of your 
information is contained in the spatial and temporal ordering of your primitive elements rather 
than the values of the elements themselves.  The same is true for a lot of "semi-structured 
data."  The problem is that the relational model, by explicit design, doesn't concern itself with 
ordering; relations are *sets*, dammit.  This means that the ordering information has to be 
encoded and decoded by explicit application logic, which takes time and space (for the data 
elements whose only purpose is to "thread" others).

To a large extent, the relational model's ability to abstract away ordering concerns has been its 
big strength when dealing with the sort of data in which ordering issues were historically matters 
of internal implementation detail rather than essential features of the data itself.  But that 
strength turns into a weakness when dealing with the type of data where order carries (most of 
the) genuine information.  This is why neither the relational model nor XML nor anything else can 
fulfill the role of a Grand Unified Model (GUM); the entire purpose of a model is to abstract away 
the "irrelevant" features of whatever it is that's being modeled, and what is or is not relevant 
depends on the problem domain.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS