Re: using path notation /../../.. for hierarchy

From: Marshall Spight <mspight_at_dnai.com>
Date: Mon, 09 Jun 2003 00:23:24 GMT
Message-ID: <0sQEa.93901$DV.112698_at_rwcrnsc52.ops.asp.att.net>


"henq >" <henq _ replace 0 by o <hvtijen_at_h0tmail.c0m> wrote in message news:3ee325f1$0$76753$1b62eedf_at_news.wanadoo.nl... >
> So I am curious, is my approach discussed earlier ...

It sounds like XPath.

The basic problem with what you're describing is the general trait of programmers to shoehorn non-tree datastructures into trees, possibly because trees are so easy to understand. For example, no university or even high school that I know of offers diplomas based on a simple one-to-many relationship within their course catalog. (Although perhaps I have not understood you.) This is better expressed as a many-to-many relationship. But outside of the database world, (that is, in the applications world) many-to-many relationships aren't handled that well or that regularly. I think this is the central defect of XML (well, besides the appalling syntax) and also the unimagined blind spot of many application or OO programmers.

> and what does the c.d.t.
> community think of using path notation in this manner?

I think they're going to like relations better.

One big advantage of relations over what you're describing is the fact that there is a single uniform approach to data. All structural information in a relation is encoded as data, and all data is data, and there is a uniform way to query and update data. That means you have exactly one way to query and update both data and structure. In tree-oriented systems, there is one way to query and update structure and a different way to query and update data. That's more complicated, although perhaps more "intuitive."

Marshall Received on Mon Jun 09 2003 - 02:23:24 CEST

Original text of this message