You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeremy Quinn <je...@media.demon.co.uk> on 2001/12/01 12:44:19 UTC
Re: Personal comments on XUpdate
At 7:38 pm +0100 30/11/01, Stefano Mazzocchi wrote:
>I've just reread the XUpdate spec. Here are my quick comments:
>
>1) no namespace support. I mean, there is no namespace concept taken
>into consideration in the spec.
>
>This would, *alone*, make it virtually useless for any serious XML
>storage.
agreed, if we keep to the spec that is .....
>2) extremely verbose: their example
[snip]
agreed
Why have "command" special tags for insertion, then have internal inline
content?
>
>3) mixes concerns or duplicates them:
>
>why would you *ever* want to "rename" a node using something like this?
>This mixes concerns: renaming and moving stuff around is an
>administration concern, not an "update" concern.
you provide the functionality only to the people who manage that particular
concern
>what's the semantic difference between "append" and "insert-after"? I
>can't find any.
yes, this is confusing, my understanding is that "insert-after", inserts a
new node after the context node, inside the context node's parent, while
"append" adds the new node to the context node itself, ie, could be renamed
"insert-into".
>4) adds variable support, which might be mixing concern with the XQuery
>language.
[snip]
>I consider this a big design mistake and probably a vary dangerous path
>to follow: IMO, the querying should happen *before* the XUpdate document
>is even generated. So, variables are useless.
I imagine they thought it would be nice to copy info from one place to
another during an update
> - o -
>
>Net result: as it stands right now, I would avoid it as the plague.
>
>With proper namespace support, better use of attribute-based semantics
>and no variables, it would be "decent".
>
>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.
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.
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!!!
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.
thanks
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 1:09 pm +0100 1/12/01, Michael Hartle 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!!!
>>
>>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.
>>
>I guess XUpdate is depending on input as almost every other process of
>standardization; what about actively participating on the evolution of
>XUpdate instead of distant, probably unheard evaluation ? I think that
>Stefanos view should be pointed out to the spec maintainers of XUpdate,
>in order to try spark discussions and enhancements on the side of XUpdate.
Problem is, we reckon the lexus project (that developed it) is dead.
Now XML:DB is moving over to Apache, it is the perfect time to work out
more ideal techniques for update.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle wrote:
>
> Stefano Mazzocchi wrote:
>
> >Michael Hartle wrote:
> >
> >>I guess XUpdate is depending on input as almost every other process of
> >>standardization; what about actively participating on the evolution of
> >>XUpdate instead of distant, probably unheard evaluation ? I think that
> >>Stefanos view should be pointed out to the spec maintainers of XUpdate,
> >>in order to try spark discussions and enhancements on the side of XUpdate.
> >>
> >Really?
> >
> >In case it wasn't clear my comments on XUpdate are: totally useless and
> >dangerous, there is no need for such a language.
> >
>
> As I read
>
> <quote>
>
> > Net result: as it stands right now, I would avoid it as the plague.
> >
> > With proper namespace support, better use of attribute-based semantics
> > and no variables, it would be "decent".
> >
> > 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.
>
> </quote>
>
> in your first post, I understood that as if XUpdate wasn't a completely
> lost cause, but needed some guidance. Well, if Lexus is dead and XML:DB
> on the way under the Apache umbrella, this looks like an alternative. :-)
My first post was based on a very superficial view of the technology.
My second post was written after a detailed look at the latest spec.
I agree with Jeremy that the ability to modify documents by
adding/replacing document fragments is required.
But I have the perception that it's a matter of adding functionality to
the XML:DB API rather than creating a markup language for it.
Of course, this is only my personal opinion.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>Michael Hartle wrote:
>
>>I guess XUpdate is depending on input as almost every other process of
>>standardization; what about actively participating on the evolution of
>>XUpdate instead of distant, probably unheard evaluation ? I think that
>>Stefanos view should be pointed out to the spec maintainers of XUpdate,
>>in order to try spark discussions and enhancements on the side of XUpdate.
>>
>Really?
>
>In case it wasn't clear my comments on XUpdate are: totally useless and
>dangerous, there is no need for such a language.
>
As I read
<quote>
> Net result: as it stands right now, I would avoid it as the plague.
>
> With proper namespace support, better use of attribute-based semantics
> and no variables, it would be "decent".
>
> 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.
</quote>
in your first post, I understood that as if XUpdate wasn't a completely
lost cause, but needed some guidance. Well, if Lexus is dead and XML:DB
on the way under the Apache umbrella, this looks like an alternative. :-)
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle 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!!!
> >
> >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.
> >
> I guess XUpdate is depending on input as almost every other process of
> standardization; what about actively participating on the evolution of
> XUpdate instead of distant, probably unheard evaluation ? I think that
> Stefanos view should be pointed out to the spec maintainers of XUpdate,
> in order to try spark discussions and enhancements on the side of XUpdate.
Really?
In case it wasn't clear my comments on XUpdate are: totally useless and
dangerous, there is no need for such a language.
I don't think these comments will likely spark discussions and/or
enhancements on the side of XUpdate :)
I don't think it's even worth the energy since it's the very concept
about an updating language that I find useless for semi-structured data.
Of course, it makes sense for structure data, but here, what it doesn't
make sense is the use of native XML databases to store data that is
easily stored into a relational database.
But I have the impression my thoughts are simply too inflammatory on
data-oriented communities so I'd keep them around here.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Michael Hartle <mh...@hartle-klug.com>.
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!!!
>
>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.
>
I guess XUpdate is depending on input as almost every other process of
standardization; what about actively participating on the evolution of
XUpdate instead of distant, probably unheard evaluation ? I think that
Stefanos view should be pointed out to the spec maintainers of XUpdate,
in order to try spark discussions and enhancements on the side of XUpdate.
Best regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Writing a Transformer, getting a Serializer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 10:25 am +0100 4/12/01, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>>
>> At 4:30 pm +0100 3/12/01, Stefano Mazzocchi wrote:
>> >Jeremy Quinn wrote:
>> >
>> >> Is this possible?
>> >
>> >Is shouldn't.
>> >
>> >> Am I looking at this the right way?
>> >
>> >I think so, what are you trying to achieve?
>>
>> XML File editing from HTML forms.
>>
>> Request Generator
>>
>> Followed by XSLT StyleSheet to set up XInclude tags
>>
>> Xinclude the editable content
>>
>> XSLT StyleSheet modifies the XIncluded content, using the output of the
>> request generator.
>>
>> This content is then passed on to a "FileResourceWriterTransformer", which
>> (either reacting to a namespace in the content or has been told which tag)
>> outputs that content as a file on disk.
>>
>> Response prepared for user
>>
>> I need my Transformer to Serialise the Sax Events "between" it's trigger
>> tags, to a File, provided a (pseudo protocol) URL.
>
>Yes, this is more of an architectural question. For now, you can't call
>a serializer like that. And I have the perception it would be wrong to
>allow you to do it.
>
>I would simply call the the serializing code that the XML serializer
>uses, it's a couple of lines of code anyway.
>
>> Serialisers can be set up in different ways, so I thought it would be good
>> to allow the SItemap author to be able to tell the Transformer to use a
>> Serialiser already setup in the SiteMap.
>
>I'm not that sure since your outside behavior is still that of a
>transformer if you are taking input and placing output.
>
>The use of Serializers would be justified if you considered the need for
>plugging in different serialization behavior, but I only see the need
>for the XML serialialize, so my suggestion is to call the serialization
>routines directly.
>
>> Hence my need to get a Serialser by it's sitemap name, whilst inside my
>> Transformer.
>>
>> Does that make any more sense ;) ?
>
>Yes, but I'd call it FS: if you need to serialize it doesn't necessarely
>mean that you need a the whole abstraction of the serializer concept :)
>Don't you agree?
Thanks for the reply.
Makes sense, I'll try it like you suggest.
People may still want to set character-set and indentation of the serialsed
XML, or is the character-set treated transparently?
In fact I don't really understand the issues of Character Sets here, can
anybody help?
Assuming that you do not want to change the character-set of a document
that you are inserting Nodes into, and it might be anything, and you don't
know what character-set the Request is going to be, what do you do?
This is something I never worked out properly in the FP TagLib, and it
caused problems for people not using utf-8, I'd rather get it right this
time ;)
Thanks for your help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Writing a Transformer, getting a Serializer
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> At 4:30 pm +0100 3/12/01, Stefano Mazzocchi wrote:
> >Jeremy Quinn wrote:
> >
> >> Is this possible?
> >
> >Is shouldn't.
> >
> >> Am I looking at this the right way?
> >
> >I think so, what are you trying to achieve?
>
> XML File editing from HTML forms.
>
> Request Generator
>
> Followed by XSLT StyleSheet to set up XInclude tags
>
> Xinclude the editable content
>
> XSLT StyleSheet modifies the XIncluded content, using the output of the
> request generator.
>
> This content is then passed on to a "FileResourceWriterTransformer", which
> (either reacting to a namespace in the content or has been told which tag)
> outputs that content as a file on disk.
>
> Response prepared for user
>
> I need my Transformer to Serialise the Sax Events "between" it's trigger
> tags, to a File, provided a (pseudo protocol) URL.
Yes, this is more of an architectural question. For now, you can't call
a serializer like that. And I have the perception it would be wrong to
allow you to do it.
I would simply call the the serializing code that the XML serializer
uses, it's a couple of lines of code anyway.
> Serialisers can be set up in different ways, so I thought it would be good
> to allow the SItemap author to be able to tell the Transformer to use a
> Serialiser already setup in the SiteMap.
I'm not that sure since your outside behavior is still that of a
transformer if you are taking input and placing output.
The use of Serializers would be justified if you considered the need for
plugging in different serialization behavior, but I only see the need
for the XML serialialize, so my suggestion is to call the serialization
routines directly.
> Hence my need to get a Serialser by it's sitemap name, whilst inside my
> Transformer.
>
> Does that make any more sense ;) ?
Yes, but I'd call it FS: if you need to serialize it doesn't necessarely
mean that you need a the whole abstraction of the serializer concept :)
Don't you agree?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Writing a Transformer, getting a Serializer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 4:30 pm +0100 3/12/01, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote:
>
>> Is this possible?
>
>Is shouldn't.
>
>> Am I looking at this the right way?
>
>I think so, what are you trying to achieve?
XML File editing from HTML forms.
Request Generator
Followed by XSLT StyleSheet to set up XInclude tags
Xinclude the editable content
XSLT StyleSheet modifies the XIncluded content, using the output of the
request generator.
This content is then passed on to a "FileResourceWriterTransformer", which
(either reacting to a namespace in the content or has been told which tag)
outputs that content as a file on disk.
Response prepared for user
I need my Transformer to Serialise the Sax Events "between" it's trigger
tags, to a File, provided a (pseudo protocol) URL.
Serialisers can be set up in different ways, so I thought it would be good
to allow the SItemap author to be able to tell the Transformer to use a
Serialiser already setup in the SiteMap.
Hence my need to get a Serialser by it's sitemap name, whilst inside my
Transformer.
Does that make any more sense ;) ?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Writing a Transformer, getting a Serializer
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
> Is this possible?
Is shouldn't.
> Am I looking at this the right way?
I think so, what are you trying to achieve?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Writing a Transformer, getting a Serializer
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 10:49 am +0000 2/12/01, Jeremy Quinn wrote:
>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.
Would someone mind helping me with some Cocoon internals?
I am pretty sure I know how to write a Transformer (at least I have some
great examples!), but I do not know how to get a Serialiser inside a
Transformer.
What I am thinking of is this:
I would like to pass as a parameter to the Transformer, the name of the
Serialiser (as set up in the SiteMap), that you want the Transformer to use
when it writes out your XML Fragment to file.
Something like this:
<map:transformers default="xslt">
<map:transformer
name="write-file"
src="org.apache.cocoon.transformation.FileResourceWriterTransformer"
pool-max="16" pool-min="8" pool-grow="2">
<serializer>xml</serializer> <!-- say which Serialiser to use -->
</map:transformer>
</map:transformers>
<map:serializers default="html">
<map:serializer name="xml"
mime-type="text/xml"
src="org.apache.cocoon.serialization.XMLSerializer"
pool-max="32" pool-min="16" pool-grow="4">
<omit-xml-declaration>no</omit-xml-declaration>
</map:serialzer>
</map:serializers>
<map:pipeline>
<map:match pattern=" ... ">
<map:generate ...../>
<map:transform type="write-file" src="cocoon:/thefile.xml">
<!-- the Node in the current document, that is
to become the root Node of the saved file-->
<map:parameter name="file-root" value="doc"/>
</map:transform>
<map:serialize>
</map:match>
</map:pipeline>
Then in the "compose()" method, I want to take the (SiteMap) name of the
Serialser, and retrieve the Component, releasing it in the "dispose()"
method.
Is this possible?
Am I looking at this the right way?
Thanks for any help
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
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
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal comments on XUpdate
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org