At 7:38 pm +0100 30/11/01, Stefano Mazzocchi wrote:
>I've just reread the XUpdate spec. Here are my quick comments:
>
>1) no namespace support. I mean, there is no namespace concept taken
>into consideration in the spec.
>
>This would, *alone*, make it virtually useless for any serious XML
>storage.
agreed, if we keep to the spec that is .....
>2) extremely verbose: their example
[snip]
agreed
Why have "command" special tags for insertion, then have internal inline
content?
>
>3) mixes concerns or duplicates them:
>
>why would you *ever* want to "rename" a node using something like this?
>This mixes concerns: renaming and moving stuff around is an
>administration concern, not an "update" concern.
you provide the functionality only to the people who manage that particular
concern
>what's the semantic difference between "append" and "insert-after"? I
>can't find any.
yes, this is confusing, my understanding is that "insert-after", inserts a
new node after the context node, inside the context node's parent, while
"append" adds the new node to the context node itself, ie, could be renamed
"insert-into".
>4) adds variable support, which might be mixing concern with the XQuery
>language.
[snip]
>I consider this a big design mistake and probably a vary dangerous path
>to follow: IMO, the querying should happen *before* the XUpdate document
>is even generated. So, variables are useless.
I imagine they thought it would be nice to copy info from one place to
another during an update
> - o -
>
>Net result: as it stands right now, I would avoid it as the plague.
>
>With proper namespace support, better use of attribute-based semantics
>and no variables, it would be "decent".
>
>I'll try to come up with something because, as it stands, I would be
>very -1 in basing Cocoon XML persistant capabilities on such a spec.
fair enough ..... (and I am NOT arguing FOR XUpdate here .....)
However, what you have subsequently written (your "[RT] Dreams for a useful
database" thread, and very interesting it is too!) is looking at the issue
of CMS in too narrow a view IMHO.
For instance, when I have done projects based on files, and when I have
remade the same projects using XMLDB, it makes sense to use a different
"granularity" of xml fragment.
Example 1. say I have a bunch of articles of around 20 - 50K text, if I am
basing the site on files, it is simplest to have the whole article in one
file, and jump from chapter to chapter internally. Doing this in XML:DB, I
find it easier to place each "chapter" (or even smaller) in separate
documents within the same collection.
Example 2. I am making a guest book for the site, if it was file-based, I
would be keeping all the entries in one file, xml:db based, and I have each
guest as a document in a collection.
Depending on the datasource, we will need to do different types of
operations to modify them. In the case of a guest book based on files, you
legitimately want to be able to insert nodes into existing xml fragments,
while in xml:db, I only ever want to add new documents.
The XUpdate language (however flawed) looks to me designed primarily for
inserting stuff into existing fragments, it is not expressive in terms of
adding new documents to collections, or files to filesystems.
We need to be able to do both!!!
That said, yes I am very interested in finding an alternative to XUpdate,
but please do not forget that some of what it does is useful and IMHO
relevant.
thanks
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
