cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Personal comments on XUpdate
Date Fri, 30 Nov 2001 18:38:31 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message