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 ....
<snip/>
>> 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
document.
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
>@cms:latest='true']
>
>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!
>
>good
>
>> 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
>content.
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:/"/>
</map:transform>
<!-- 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"/>
</map:match>
(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
control).
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
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
