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 Mon, 03 Dec 2001 15:24:37 GMT
At 12:46 pm +0100 3/12/01, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:

>> How do you want to specify where the {prepend|replace|append} goes, with an
>> XPath?
>At the API level:
> Location loc = database.getLocation(xpath);
>then you pass the location object with what to insert (using an
>outputstream or a contentHandler)

Yea, sorry, I am trying to understand it from a the point of view of the
SiteMap, probably jumping the gun ....


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

You have definitely picked up on a large chunk of what I meant, below and I
agree with a lot of what you say, however, I think there is more ....

>> 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).
>Oh, I don't know about "everyone" but I'm sure I won't stop pushing
>until it suits my personal needs. If everybody does this, it will suits
>"everyone involved", which is normally good enough (well, it has been
>around here so far).

I agree about the collaboration bit ;)

But I think you may have missed the point about granularity, one of the
reasons I think a one-size-fits-all scheme for versioning would be
difficult, would be that people will have different legitimate requirements
for the granularity of the versioning.

For instance, if I have long articles stored as single blobs and someone
edits a few words here and there, a couple of times, I'd find it far more
efficient to version at say the paragraph level rather than the whole

I was not sure this was implied in your original email.

>> 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']
>This is a very good question.
>In a perfect world, we would have a version-agnostic db engine down
>below and a versioning wrapper that would transform/adapt queries to
>take versioning into consideration. Something like
> +----------------------------+
> | Versioning/Workflow XML DB |
> |  +-----------------------+ |
> |  | Native XML DB         | |
> |  +-----------------------+ |
> +----------------------------+
>So, you would ask the CMS for
> //article//author[@name="Jeremy"]
>and the versioning layer will adapt this into
> //article//author[@name="Jeremy" and @cms:status="published" and
>I see two problems:
> 1) performance

This is all potentially cacheable, no?

> 2) space

Why keep all old versions in the "active" storage area?

If you only need a couple of versions like the current one and any active
under-development workflow versions, then off-load the rest to cvs://
javaspace:// etc.

Hopefully the wrapper/toolkit approach can provide a way for people to put
together their own appropriate solution

>(the two are related)
>I mean, versioning and workflow could simply be considered metadata.
>Since the native XML DB must be namespace capable in both elements and
>attributes, we could use specific namespaces to indicate our metadata
>(both as wrapping elements or as marking attributes).
>My perception is that my making these metadata built-in into the DB,
>query performance would be faster and database size would be reduced.
>But at the same time, as a first implementation, it's probably the way
>to go to show off the power of such a concept.
>> >> 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.
>Yeah, it might give you (and us) more insights and ideas.
>Anyway, I'll rethink about adding versioning/workflow information as
>metadata on existing native DB systems and understand how complex would
>that be to implement and how that would impact updating/inserting

I have been experimenting with a further abstraction layer I call LinkMap.

The LinkMap represents a site (or subsite) structural heirarchy using
XLinks which implement a mapping between named resources in the site and
internal pipelines in Cocoon. This is how it is used in the SiteMap:

			<map:match pattern="*">
				<map:generate src="xlink/linkmap.xml"/>
				<!-- setup for XInclude -->
				<map:transform src="xsl/linkmap-cincl.xsl">
					<map:parameter name="id" value="{1}"/>
					<map:parameter name="context" value="cocoon:/"/>
				<!-- import document and linkbase -->
				<map:transform type="cinclude"/>
				<map:transform src="xsl/linkmap-xlink.xsl"/>
				<map:transform src="xsl/linkmap-html.xsl"/>
				<map:serialize type="html"/>

(I'll write an RT about it if you like :)
I get automatic link glossaries and page context stuff like a site tree,
page path and local nav.

I was thinking that either XLinks in your XML:DB, or some kind of link
glossary idea that maps static "url names" to the currently valid asset
somewhere, might be easier and provide a point of human intervention (or

That is to say, instead of keeping all versioning info together in one
expensive to extract parcel have a clean version in your active serving
datastore and a way of either moving versions around or add a further layer
of abstraction and map that url to a different version.

Anyway, enough for now, I've got to get back to work =:-O

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