Cart
[Home] [By Thread] [By Date] [Recent Entries]
>> > 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. >Techniques >> include ID/IDREF, XLink/XPointer, RDF, TM etc, etc. The easy and >efficient >> 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 document. 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 : simplicity. 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 >and >> voice which is interpreted by humans in a nonlinear, non serial >fashion. > >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. >-J 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. Regards, Nicolas
|
