[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Designing XML to Support Information Evolution

• To: Michael Champion <mc@x...>
• Subject: Re: Designing XML to Support Information Evolution
• From: Rick Marshall <rjm@z...>
• Date: Fri, 21 May 2004 09:52:49 +1000
• Cc: "xml-dev DEV'" <xml-dev@l...>
• In-reply-to: <33BAB7D2-AA62-11D8-AD46-000A95CCC59E@x...>
• Organization: Zenucom Pty Ltd
• References: <830178CE7378FC40BC6F1DDADCFDD1D102766E4F@R...> <33BAB7D2-AA62-11D8-AD46-000A95CCC59E@x...>
• User-agent: Mozilla Thunderbird 0.6 (X11/20040502)

hierarchies fail, and this is my struggle with xml at the moment, when 
they have to support multiple hierarchies simultaneously. and they 
largely fail because of a) the update problem, and b) the new hierarchy 
problem. reverse bill of materials is a case in point.

having said that xml works really well where neither of these are an 
issue - documents where the "semantics" don't change only the contents; 
and as i said before moving transactions between systems.

even relational systems have problems because the semantics is embedded 
in the sql select statements. most so called post relational systems 
(not really sure that's a legitimate term, even though it's used a lot) 
basically embed semantics back into the structure.

things like owl and to a lesser extent name spaces try to express the 
semantics as a meta model. imho a far superior approach. i just don't 
like naming relationships - prefer to acknowledge they exist and what it 
takes to define them, but not necessarily name them.

now to xml and the cinderella id tag. the same effect as the 
hierarchical xml could be achieved by allowing a name/value pairing to 
store the structure as attributes in the xml tag and they should be 
treated as elements as well.

the id tag is the required unique key, while special associate elements 
store structure. this has the advantage of flatenning the xml and 
allowing the parsers to create structure on the fly to suit the translators.

<home id="456"><home_elements/></home>
<person id="123"><associate 
type="home">456</associate><other_elements/></person>

which would be approximately

<home id="456">
    <home_elements/>
    </home>
<person id="123">
    <home>456</home>
    <other_elements/>
    </person>


early days, but something like this would be much better for data 
modelling. perhaps we can have post-xml?  ;)

rick




Michael Champion wrote:

>
> On May 19, 2004, at 10:37 AM, Dare Obasanjo wrote:
>
>> Hierarchical databases failed for a reason.
>
>
> Just to be pedantic, the hierarchical model failed, hierarchical 
> databases are still chugging along.  IMS (a hierarchical DBMS that is 
> the meanest, nastiest, ugliest mainframe dinosaur) still quietly 
> manages an awfully big chunk of the world's data:  "More than 
> ninety-percent of the Fortune 1000 companies use IMS. IMS serves 200 
> million end users, managing over 15 billion Gigabytes of production 
> data and processing over 50 billion transactions every day."
> http://www-306.ibm.com/software/data/ims/highlights/experform.html
>
>  25 years or so ago, Codd conclusively demonstrated the superiority of 
> the relational model, but  the world seems to keep reinventing 
> hierarchical databases, AKA post-relational DBMS, Object-Relational 
> RDBMS with an XML column type, native XML DBMS, even OODBMS (note that 
> Progress has given ObjectStore new life since they bought Excelon, 
> presumably because it has a lucrative niche). This happens because an 
> awful lot of real-world relationships are hierarchical -- "contains / 
> part-of", "parent / descendent", "manages / managed-by" .... -- and it 
> is pragmatic to use tools that natively understand hierarchy to deal 
> with them.  Likewise, lots of things are intrinsically ordered (time 
> being the obvious one) and as best I understand it, temporal 
> relationships are one of the weaker aspects of the relational model 
> even in theory, nevermind practice; again, XML treats order as a 
> first-class citizen and is often a pragmatic tool.
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>

begin:vcard
fn:Rick  Marshall
n:Marshall;Rick 
email;internet:rjm@z...
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard

• Follow-Ups:
  • RE: Designing XML to Support Information Evolution
    • From: "Michael Kay" <michael.h.kay@n...>
  • Re: Designing XML to Support Information Evolution
    • From: Robert Koberg <rob@k...>

• References:
  • RE: Designing XML to Support Information Evolution
    • From: "Dare Obasanjo" <dareo@m...>
  • Re: Designing XML to Support Information Evolution
    • From: Michael Champion <mc@x...>

• Prev by Date: Re: ebXML for BIS
• Next by Date: Re: Designing XML to Support Information Evolution
• Previous by thread: Re: Designing XML to Support Information Evolution
• Next by thread: Re: Designing XML to Support Information Evolution
• Index(es):
  • Date
  • Thread