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] heritage (was Re: [xml-dev] SGML on the Web)

[ Lists Home | Date Index | Thread Index ]

Michael,

Michael Kay wrote:

>>Sorry, that is simply not correct.
>>
>>Underlying XML is a data model. That data model is set forth at: 
>>http://www.w3.org/XML/Datamodel.html
>>
>How interesting. But go up a page, and you find:
>
>"This page collects some thoughts on XML and links to some software. It
>dates from 1997 and is not currently maintained."
>
>Not exactly a normative reference.
>
It appears that Jeni and I have reached at least an understanding that 
XML syntax can be considered "as though" it was based upon a tree model.

I concede that I should have read the cited page more carefully but the 
data model of XML is so obviously a tree that I did not. Carelessness on 
my part but I was surprised that anyone would claim that XML did not 
have an underlying data model. The other models cited by Jeni (with the 
exception of SAX with is an event model) are merely ways of describing 
relationships based upon an underlying tree model.

I concede that XML has no normative data model but as Sam Hunting 
pointed out yesterday, XML parsers process an XML document from a single 
root and as a single tree. To me if it walks like a duck, talks like a 
duck and has all the limitations of a duck, I have a strong suspicion 
that it is a duck.

Trees are incredibly useful views of data as Jeni pointed out yesterday 
and I do not dispute that statement. It is the non-existent data model 
requirement that XML syntax (in Jeni's use of the term) be limited to a 
single tree (with or without overlapping, which is only one of the 
problems with XML syntax) that I find troubling.

As the complexity of data to which XML is applied increases, so will the 
problems caused by the assumptions (if you don't like the term data 
model) that underlie XML. Jeni has proposed one solution to address more 
complex data requirements and I have proposed another. I think the 
markup community as a whole will be served by a discussion of the strong 
and weak points of XML. But I would open that discussion up to include 
fundamental assumptions of XML, as XML, and not advocate creating 
research languages other than for use in investigating where XML went 
wrong.

Patrick


>
>Michael Kay
>Software AG
>home: Michael.H.Kay@ntlworld.com
>work: Michael.Kay@softwareag.com 
>
>
>-----------------------------------------------------------------
>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://lists.xml.org/ob/adm.pl>
>

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu







 

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

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