[
Lists Home |
Date Index |
Thread Index
]
>Where does that leave XML? Well, I don't think designing an XML document
>by specifying a schema is designing a database. Clearly, it is related -
>the domains used in the message should correspond to domains in the
>applications it applies to. But there is no modeling of operations on
>the schema. There are constraints, but they are constraints on unrelated
>instances of the schema (a database constraint is for transforming one
>instance into another).
Methinks you are right. Perhaps a way of looking at this is the old
classical computer "posting problem". I remember first reading a complete
description of this in a text (circa 1965-1970) by Ivan Flores. (this was
when state of the art was updating very large data sets stored on magnetic
tape from very large transaction sets also on magnetic tape or <gasp/>
punched cards).
This was the idea of having a "master file" (database) and one or more
"transaction files" that had to be "posted" to the master file. The master
file would then subsequently be used to generate one or more transaction
files and/or report files. [I worked with a generic solution to this problem
once - it was called MARKIV]
XML documents seem to me to be "transactions" which can be posted to a
"database". The transaction can get burst and filed as resusable
information parts with configuration mgmt and version control(document
management) - or update a portion of the database (e.g. order entry or
banking) and these are all valid operations (create, update, delete). The
design of the database and the design of the transactions are as you say
related - but not the same.
I have always tended to view an XML document as a transaction.
Cheers...Hugh
W. Hugh Chatfield I.S.P.
CyberSpace Industries 2000 Inc.
XML Consulting & Training
|
