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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Data storage, data exchange, data manipulation

>> > I don't think a node-labeled tree (the XML model is a tree, more
>> > restricted than a graph) structure can model all kind of data
>> > easily and efficiently.
>> There is a wealth of discussion on representing graphs in XML.
>> include ID/IDREF, XLink/XPointer, RDF, TM etc, etc. The easy and
>> part depends on the implementation.
>Right, I think calling XML a tree is oversimplification.  The web is a
>graph.  XML is the web made just a bit less sloppy, but we still have
>key/keyref and XLink, XPointer, RDF -- all that stuff John mentions.
>Take the graph that is the web and make it more machine-readable.  Take
>all of the services and data in silos at the edges of the web and expose
>it as XML documents (as appropriate of course).  Now you have one big
>huge honkin' graph.  What is more fun that that?  I agree that
>implementation is hard; but that's why we get paid.

Do you mean that two XML documents linked together through an XLink/XPointer
link always form a new XML document ? For me, they don't.  However two
documents linked together using XInclude *always* do form a new XML

Linking two documents together in a non hierarchical way is much like
building a XML document for a graph using ID/IDREF for non-hierarchical
links : you're doing tricks by adding new, external rules to the core rules
of XML. Keep adding new rules and you will loose the reason of XML success :

I may be too purist, but I think ID/IDREFs are a way to escape the
hierarchical model. The trouble is that there is a lot of assumptions about
data structured in a hierarchical way that you cannot do if non-hierarchical
links are provided through ID/IDREFs or other systems.

For example, you can process an XML document without ID/IDREFs in a rather
straightforward way using SAX. With ID/IDREF you have to store a reference
to every element with an ID of IDREF in order to resolve the links in a
second pass (e.g. if the IDREF precedes the ID). This is quite expensive in
memory and CPU (it's the good old DOM vs. SAX issue).

>> > can exchange data with a human being are serial, and I feel that>
>> > hierarchised text or speeches are the highest form of structured,
>> > serialized data that we can understand.
>> actually humans are not limited to serial data formats, e.g. images
>> voice which is interpreted by humans in a nonlinear, non serial
>Yeah, depends on what you mean by "understand".  There is the old rule
>of thumb that people can't keep a list of more than 7 things in mind at
>a time, yet we routinely have databases with millions of rows, and lists
>on this mailing list can be as large as 80 greek words at a time.

What you present to people in a browser are more likely hierarchical lists
of length 7 rather than a million rows of relational data. I don't know
anybody who reviews a million rows of data to make a decision. A
hierarchical report analysing and aggregating this million rows of into
different views is way more interesting. That's why I think, even if the
underlying data storage is not hierarchical, that the hierarchical model is
well suited for reporting and presentation of data to human beings.