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

Re: Designing XML to Support Information Evolution

• To: Rick Marshall <rjm@z...>
• Subject: Re: Designing XML to Support Information Evolution
• From: Robert Koberg <rob@k...>
• Date: Thu, 20 May 2004 17:53:04 -0700
• Cc: Michael Champion <mc@x...>, "xml-dev DEV'" <xml-dev@l...>
• In-reply-to: <40AD44D1.4060509@z...>
• Organization: liveSTORYBOARD
• References: <830178CE7378FC40BC6F1DDADCFDD1D102766E4F@R...> <33BAB7D2-AA62-11D8-AD46-000A95CCC59E@x...> <40AD44D1.4060509@z...>
• User-agent: Mozilla Thunderbird 0.6 (Macintosh/20040502)

Rick Marshall wrote:

> hierarchies fail, 

hmmm... isn't the internet a hierarchy? has that failed?


> 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

• Follow-Ups:
  • RE: Designing XML to Support Information Evolution
    • From: "Michael Kay" <michael.h.kay@n...>
  • Re: Designing XML to Support Information Evolution
    • From: Rick Marshall <rjm@z...>

• 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...>
  • Re: Designing XML to Support Information Evolution
    • From: Rick Marshall <rjm@z...>

• Prev by Date: Re: Designing XML to Support Information Evolution
• 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