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] Designing XML to Support Information Evolution

[ Lists Home | Date Index | Thread Index ]

Robert Koberg wrote:

> Rick Marshall wrote:
>
>> hierarchies fail, 
>
>
> hmmm... isn't the internet a hierarchy? has that failed?

the internet addressing is, the www isn't - it's a large associative 
memory and i'd be willing to argue that's exactly why it works.

the internet works because you find machines by following routers, often 
going up and down hierarchies to get to them. but routers can put 
non-hierarchical links into the system. there's often more than one way 
to get between machines.

rick

>
>
>> 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
>
>

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





 

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

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