Said another way again: since we have a good, conceptually clear
standard for describing the objects we want to update, we are well-
placed to 'go the extra mile' and define a standard for updating those
objects.
May we return to SQL, as a precedent for the type of language Joe was
originally asking about? SQL's primary purpose is to support the use
and updating, of distributed database information, by multiple users, in
real time. Surely that is a reasonable expectation for XML information,
too?
If so, we need mechanisms to specify changes to existing documents. I
don't really buy the model that says that every change to an XML
document produces a completely new document. You will certainly have a
hard time selling that idea to an end-user who changes one word in a
document, or to a database vendor who has to take back the complete
document and work out for themselves what (if anything) has changed, in
order to update the relevant nodes.
Also, in the real world you need access control (c.f. GRANT in SQL).
The very nature of XML documents means that this control needs to be at
the node rather than the document level, if only to deal with entities.
Also, you need to know which parts of the document you are allowed to
change as you start editing - it is not good enough to be told some time
afterwards that certain changes should not have been made!
I agree that you can perfectly well define changes to an XML document
via its representation as a grove, but this grove needs to be linked
back to the physical objects that gave rise to it. For example, if you
edit a phrase that happens to be within an entity that is referenced
more than once within the document you are editing, then perform an
UPDATE, in principle _all_ references to that entity should be updated.
Richard Light.
Richard Light
SGML/XML and Museum Information Consultancy
richard@light.demon.co.uk