On Monday, 27. January 2003 21:47, S Woodside wrote:
> [if you want me to stop posting these thoughts to the list, tell me]

I like to read them. Though I can't always follow you, I am definitely 
interested in the outcome. Maybe a great tool will arise, maybe you will 
scrap it all, time will tell ;-)

> in the output. Hmm... doesn't look like there's much implementation
> using XUpdate out there, based on google, that's not a good thing.

I use XUpdate now on a regular basis, as I am using Xindice as database. 
Search for XML::DB for perl via google (unfortunately it's not on CPAN).

After implementing the very first modification jobs as 
retrieve-manipulate_dom-store, I took a look at XML::DB's inherent XUpdate 
capability (either through libxml or through the backend db) and I love it. 
It gives you all the flexibility of SQL's UPDATE statement for XML.

> Also, I can foresee having to use the schema somehow to tell me where
> to insert new nodes, because getting them in the wrong order, just
> appending them on the end of the document, might create an invalid
> document. Probably the trick can be narrowed down to insertBefore or
> insertAfter as the choice.

I think you will always have a context node relative to that insertion is to 
happen. Either it's children you are adding, then xu:append is your tool, 
otherwise xu:insert-after is it.

> Chimezie's article leaves a lot to be filled on on the return trip
> http://www.xml.com/pub/a/2002/06/12/xupdate.html

You could map field names to xupdate statements.
Imagine a textfield called "update,/names/first" or a submit button called 
"insert-after,/email[last()]"... but this is dangerous: you need some way to 
make sure you don't blindly execute xupdate statements someone nasty might 
craft. Even if you validate the resulting XML, the xupdate might DoS your 
server by executing very complicated statements. So best would be to check 
against a list of possible xupdate queries. Even better, have 'normal' field 
names that you map into xupdate queries on the return trip. Either way, 
having field names/actions based on xupdate instead of node position sounds 
nice.

-- 
CU
  Joerg

PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E  7779 CDDC 41A4 4C48 6F94


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to