Re: Modeling Data for XML instead of SQL-DBMS

dawn wrote:
> mAsterdam wrote:

>> dawn wrote:
>>> mAsterdam wrote:
>>>> Hierarchy (trees of nodes),
>>>> is what IMS, documents, file systems, XML, Lotus Domino
>>>> and LDAP as data containers have in common.

>>> I think of the XML model as a di-graph where there are trees on the
>>> nodes, rather than a tree of nodes (it is only an individual document
>>> without xlink or external code joining them).  Look at each web page
>>> that is written with xhtml.  It is a tree, but there are links (<a
>>> href...>) from one page to another that form it into a di-graph.
>>> MV/Pick files are somewhat similar.
>> A unix filesystem is - at shell level - a tree.

You are still/again mixing data and implementation :-(

I'll try to spell it, though we already did go into this in quite some detail a year or so ago.

The links are not (logical/user/real) data (except in the meta case of-course, e.g. content-management systems - but let's keep it simple).

The links are not (logical/user/real) data. They are not. They are really really really not data. They do not even reference data. They are locators, pointing to a location, also called pointers.
Because they are not data, they are not part of the whole of the data.

Aren't they structural elements then?
Yes, they are part of the web (no tree) of documents and parts of documents. But they are not data-elements.

To get back to the OP-question, the (logical/user/real) data still has to be placed somewhere in the hierarchical (tree, not web) document structure.
This is a consequential choice you have to make, because of the hierarchical nature of the implementation. Characteristics of the (logical/user/real) data should/could provide guidance for this designing of the hierarchy. I am not aware of a systematic treatment of this and similar choices, though it is made - probably mostly implicitly - every day.

[snip] Received on Sat Oct 28 2006 - 23:51:12 CEST