[
Lists Home |
Date Index |
Thread Index
]
>
> The CODASYL data model ultimately foundered because of its unwieldy
> links, and XLink foundered trying to do something similar for XML.
> Maybe the lesson here is that the relational model approach of
> defining links *dynamically* based on relationships on the *values* of
> information items rather than predefined links really is the way to do
> what XLink tried to do.
>
> The thing I always liked best about XQuery is simply the addition of a
> Join operation into the XML corpus. Until this thread I hadn't
> thought of this as a replacement for XLink, but that idea is starting
> to take root in my head ... it really might be worth a look back at
> the struggle between advocates of CODASYL and those for the relational
> model to see if there is a lesson there for us.
There were of course non-technical as well as technical factors at play: IBM
didn't implement Codasyl because they were too heavily committed to IMS. In
addition, implementations of Codasyl never achieved good interoperability,
partly because the specs never stabilised adequately.
The two things that are nowadays often confused are that the Codasyl model
(a) had a network data model, and (b) had a procedural (navigational) DML.
The big step forward with relational databases was to move to a declarative
DML, but I have always felt that the same thing could have been done with a
network data model. In fact, at least on the retrieval side, several Codasyl
database systems added declarative query languages, and they were
considerably easier to use than SQL because you could follow relationships
without spelling out all the join conditions.
(Date is not a good authority on this. He was an IBMer, and most of the
action on Codasyl databases was outside the IBM sphere.)
With XPath and XQuery we currently have a read-only declarative language
over a hierarchic model. The non-hierarchic relationships are mush less well
supported.
Michael Kay
|
