Return-Path: 
 <cocoon-dev-return-19392-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 57077 invoked by uid 500); 2 Dec 2001 11:16:56 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 57066 invoked from network); 2 Dec 2001 11:16:56 -0000
Mime-Version: 1.0
X-Sender: media@pop3.demon.co.uk
Message-Id: <a05101000b82fb2d5d701@[10.0.1.40]>
In-Reply-To: <3C08F63F.E277555A@apache.org>
References: <3C07D227.35EB8C39@apache.org>
 <a05101001b82e6c03bf46@[10.0.1.40]> <3C08F63F.E277555A@apache.org>
Date: Sun, 2 Dec 2001 10:49:35 +0000
To: cocoon-dev@xml.apache.org
From: Jeremy Quinn <jeremy@media.demon.co.uk>
Subject: Re: Personal comments on XUpdate
Content-Type: text/plain; charset="us-ascii"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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
XPath?

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
>versionign)

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.

excellent

>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

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
   <phone:+44.[0].20.7737.6831>             <pager:jermq@vizzavi.net>

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