cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: Personal comments on XUpdate
Date Sun, 02 Dec 2001 10:49:35 GMT
At 4:24 pm +0100 1/12/01, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:

>> 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!!!
>Ok, point taken: what you are asking for the ability to insert document
>fragments into documents that already exist in the database.

correct, or other Resource type

>I think that what we need is just something like this:
> <whatever xmlns:x="..." x:action="...">
>  ...
> </whatever>
>where, action could be one into {prepend|replace|append}.

How do you want to specify where the {prepend|replace|append} goes, with an

We will also need "new" for generating new Resources (file/document/record etc)

>Or, even better, to allow the DB to insert stuff at any node and place
>that information directly at the API level.
>(of course, this requires some big thinking about how this impacts

Incedentally, what you were writing about earlier, having versioning as a
side effect of using XMLDB, still puzzles me.

While I find these capabilities very important, will it ever be possible to
come up with a versioning scheme that suits everyone (granularity of
information again).

Or should versioning be something that is added at the "application" level?
ie. it is not achieved by special hidden views of the DB but through the
XML Schema and the XPaths that are used to access it?

	/article/version[@status='publishable' and @latest='true']

>> 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.
>Ok, point taken and stored.


>Still, I think XUpdate is totally useless as a language since all the
>functionality should be placed at the API level.

I agree with you about the language!

Maybe I'll have a go at writing a test "FileResourceWriterTransformer", to
investigate the process of taking input from the user, having it modify a
Resource using XSLT then writing it out again.

regards Jeremy


   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
   <phone:+44.[0].20.7737.6831>             <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message