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.
2) extremely verbose: their example
<?xml version="1.0"?>
<xupdate:modifications version="1.0"
xmlns:xupdate="http://www.xmldb.org/xupdate";>
<xupdate:insert-after select="/addresses/address[1]" >
<xupdate:element name="address">
<xupdate:attribute name="id">2</xupdate:attribute>
<fullname>Lars Martin</fullname>
<born day='2' month='12' year='1974'/>
<town>Leizig</town>
<country>Germany</country>
</xupdate:element>
</xupdate:insert-after>
</xupdate:modifications>
would be *equally* meaningful as
<?xml version="1.0"?>
<address id="2"
xmlns:xupdate="http://www.xmldb.org/xupdate";
xupdate:insert-after="/addresses/address[1]">
<fullname>Lars Martin</fullname>
<born day='2' month='12' year='1974'/>
<town>Leizig</town>
<country>Germany</country>
</address>
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.
what's the semantic difference between "append" and "insert-after"? I
can't find any.
4) adds variable support, which might be mixing concern with the XQuery
language.
<xupdate:variable name="town" select="/addresses/address[0]/town"/>
<xupdate:append select="/addresses">
<xupdate:element name="address">
<xupdate:value-of select="$town"/>
</xupdate:element>
</xupdate:append>
in the rest of the spec, XPath are used as "locations" or "entry points"
for data modifications. Here, they are used as data queries.
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.
- 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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
