Jeremy Quinn wrote:
> >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?
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)
> We will also need "new" for generating new Resources (file/document/record etc)
No, that's, again, something to do at the API level.
> >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.
Please explain.
> 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).
> 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
2) space
(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.
--
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]
