[
Lists Home |
Date Index |
Thread Index
]
"W. E. Perry" wrote:
> A true XML database engine, however, can operate very much as Hugh
> Chatfield describes. A document (journal?) is submitted for commit
> (posting?) to the larger database of such documents (ledger?)
> maintained and manipulated by the database engine. Each of the
> simple CRUD operations consists primarily of this commit, and there
> is very little difference among those operations except in how
> cascading changes resulting from the data transaction must be
> carried out. The principal effect of the commit is to set the
> current or most-recent-version value of the elements (in their fully
> qualified form) present in the document committed. Beyond that,
> specific semantics must in fact be elaborated by custom processing
> which recognizes particular syntax. Think of this as database
> triggers. Where no trigger processes exist for the specific syntax
> committed, either no processing is done or an error can be raised.
> That is, however, not an error in the performance of the database
> engine, which in committing the document has done exactly what it
> was designed for. It is an error in the comprehensiveness of the
> processing provided for the data actually encountered.
<LightBulb PreviousState="Off" NewState="On" />
The trigger analogy is a very good one. I was confusing the lack of such
a "trigger" -- as might commonly be the case when storing XSLT documents
in a native XML database -- with there not being a transaction.
-- Ron
|
