Jeremy Quinn wrote:
> >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.
>
> fair enough ..... (and I am NOT arguing FOR XUpdate here .....)
>
> However, what you have subsequently written (your "[RT] Dreams for a useful
> database" thread, and very interesting it is too!) is looking at the issue
> of CMS in too narrow a view IMHO.
>
> For instance, when I have done projects based on files, and when I have
> remade the same projects using XMLDB, it makes sense to use a different
> "granularity" of xml fragment.
Fair enough.
> Example 1. say I have a bunch of articles of around 20 - 50K text, if I am
> basing the site on files, it is simplest to have the whole article in one
> file, and jump from chapter to chapter internally. Doing this in XML:DB, I
> find it easier to place each "chapter" (or even smaller) in separate
> documents within the same collection.
Ok
> Example 2. I am making a guest book for the site, if it was file-based, I
> would be keeping all the entries in one file, xml:db based, and I have each
> guest as a document in a collection.
>
> Depending on the datasource, we will need to do different types of
> operations to modify them. In the case of a guest book based on files, you
> legitimately want to be able to insert nodes into existing xml fragments,
> while in xml:db, I only ever want to add new documents.
>
> 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.
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}.
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)
> 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.
--
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]
