You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2003/02/28 13:27:12 UTC
[RT] Dynamic sitemaps
Hi,
I was idly thinking, lots of things are pointing to a future need for a
more dynamic sitemap:
- We need a way to assemble a sitemap, pulling in only the snippets that
the user needs. Eg, most people don't need the community/* support, or
XML from DTDs, or Forrest's JIRA feed.
- We need a way to let users plug in new document types, without hacking
the original sitemap.
- More and more, resource-exists actions are creeping into the Forrest
sitemap.
Right now, we're just piling more stuff into the default sitemap. The
complexity is already quite intimidating, and discourages users from
experimenting with the sitemap. Without knowing how to exploit the
sitemap's flexibility, Forrest is just a frustrating black box.
So how do we handle this problem?
I once thought auto-mounted sub-sitemaps could allow us to break up the
sitemap, but I'm rather skeptical now. Once a request is delegated to a
subsitemap, it *has* to be handled in that subsitemap. We can't
speculatively throw in a <map:mount>.
One option is to dynamically create a sitemap.xmap using XSLT, much like
the Forrestbot creates Ant scripts. Yuck..
-o0o-
Anyway, what this RT is really about is this suggestion: we use a Cocoon
pipeline to dynamically generate a sitemap, which is then mounted. We
have a 'primordial' sitemap as follows:
<map:pipeline>
<map:match pattern="sitemap">
...
</map:match>
</map:pipeline>
<map:pipeline>
<map:match pattern="**">
<map:mount uri-prefix="" src="cocoon:/sitemap" check-reload="no" />
</map:match>
</map:pipeline>
The 'sitemap' matcher then assembles a sitemap unique to the current
project. We can have configuration files which direct the assembly of
the sitemap, or even inspect the xdocs themselves (if a community/
directory is present, pull in community/* matchers). This way, we can
get rid of all those hacky resource-exists checks.
I don't know how kindly the sitemap engine would take this kind of abuse.
If it had to regenerate a subsitemap for each request, things would
certainly be too slow.
At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
Sources, but I imagine that could be fixed.
Thoughts?
--Jeff
Re: [RT] Dynamic sitemaps
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>> - We need a way to assemble a sitemap, pulling in only the snippets that
>> the user needs. Eg, most people don't need the community/* support, or
>> XML from DTDs, or Forrest's JIRA feed.
>
>
> Yeah. Seems like blocks to me.
The block design (as it stands right now) doesn't include sitemap
conditioanl capabilities, even if it is possible to do so by providing a
way for the sitemap to fall back if a resource doesn't exist.
Currently, there are no optional dependencies in the block concept: if a
block depends on that block, cocoon has to make it available or that
block won't run.
We might think of 'optional blocks' and have a precise way for teh
sitemap to fall back in case you are referring to a resource that is
contained into an 'optional' block.
That would make the conditionals if-resource-exists totally transparent
and wouldn't require additional semantics, and will make us stay away
from the evil dynamic sitemap FS!
What do you think?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [RT] Dynamic sitemaps
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jeff Turner" <je...@apache.org>
> On Sun, Mar 02, 2003 at 09:06:48PM +0100, Nicola Ken Barozzi wrote:
> ...
> > >The 'sitemap' matcher then assembles a sitemap unique to the current
> > >project. We can have configuration files which direct the assembly of
> > >the sitemap, or even inspect the xdocs themselves (if a community/
> > >directory is present, pull in community/* matchers). This way, we can
> > >get rid of all those hacky resource-exists checks.
> >
> > Hacky or not, they are conceptually needed. Your solution still checks
> > for a resource-exists, but it does it "statically". Your proposal is
> > tightly binded with the resource-exists thing.
>
> *Something* has to examine the files and construct a sitemap, but it
> wouldn't be a resource-exists action. Probably some sort of Libre-like
> generator to generate a map of the filesystem with type info, which could
> then be converted to a sitemap.
Something like this would be also useful for i18n: that *something* could
determine all the avaiable translations of a particular document,e g.:
index.xml, index_en.xml, index_ru.xml, etc and will provide that information
to the sitemap.
I'd rather see it implemented as a protocol or an input module rather than a
sitemap preprocessor/generator.
--
Konstantin
> --Jeff
>
>
Re: [RT] Dynamic sitemaps
Posted by Jeff Turner <je...@apache.org>.
On Sun, Mar 02, 2003 at 09:06:48PM +0100, Nicola Ken Barozzi wrote:
...
> >The 'sitemap' matcher then assembles a sitemap unique to the current
> >project. We can have configuration files which direct the assembly of
> >the sitemap, or even inspect the xdocs themselves (if a community/
> >directory is present, pull in community/* matchers). This way, we can
> >get rid of all those hacky resource-exists checks.
>
> Hacky or not, they are conceptually needed. Your solution still checks
> for a resource-exists, but it does it "statically". Your proposal is
> tightly binded with the resource-exists thing.
*Something* has to examine the files and construct a sitemap, but it
wouldn't be a resource-exists action. Probably some sort of Libre-like
generator to generate a map of the filesystem with type info, which could
then be converted to a sitemap.
> >I don't know how kindly the sitemap engine would take this kind of abuse.
> >If it had to regenerate a subsitemap for each request, things would
> >certainly be too slow.
>
> Resource-exists "does it" but inside a sitemap. The concept is equivalent.
>
> >At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
> >Sources, but I imagine that could be fixed.
>
> Hmmm...
>
> >Thoughts?
>
> Well, as usual I do the "divide et impera" refrain. ;-P
>
> 1 - break cocoon sitemap in snippets of functionality
> - This is what blocks will be for.
> - we can use entity includes now, and this could also
> make stefano, who is active now, work faster on blocks ;-P
>
> 2 - make it easy for users to add stuff to the pipeline
> - this would make it possible for users to add stuff to
> the sitemap without exposing it. AOP sitemap.
> the point is that Cocoon sitemap should remain
> strictly hierarchical for consistency reasons.
> So with 1 solved, the main one will be easier to
> read and can be completely exposed without fears of
> it being too messy.
Good point.
> 3 - make a better resource-exists.
> - the resource-exists paradigm is part of the easy way
> forrest makes it possible to do many things for users.
> It's the *same* conceptual thing as CAPs.
> what we need is to make it more clever WRT caching and
> source indipendent.
>
> 4 - make the CAP selector accept an external document for defining
> the DTDs, and an action that gets the relevant stylesheets
> definitions for the conversion from *DTD 2 DocumentDTD11.
If we used:
<map:resource name="transform-to-document">
...
<map:act type="sourcetype" src="{src}">
<map:transform src="resources/stylesheets/{sourcetype}2document.xsl"/>
</map:act>
</map:resource>
Then users could add new filetype support simply by creating a new
*2document.xsl stylesheet.
--Jeff
Re: [RT] Dynamic sitemaps
Posted by Nicola Ken Barozzi <ni...@apache.org>.
First let me say that I've read Stefano's mail and Jeff's reply. I will
use this mail because it's more complete WRT the actual meat of the
discussion.
Another thing: I have already done such a discussion on the cocoon-dev
ML with a guy that wanted such a system for making multiple developers
work on the same sitemap without treading on each other. I kept my
position saying that it was not good for sitemap integrity, because it
makes the devs loose control of the URI. Nobody brought in a really
compelling case... but things have changed. Forrest uses Cocoon in a way
that the original design did not envision. We are writing Cocoon stuff
for the developer, not for the site directly. So additional requirements
come into mind, like resource-exists, CAPs, etc. Let's see:
Jeff Turner wrote, On 28/02/2003 13.27:
> Hi,
>
> I was idly thinking, lots of things are pointing to a future need for a
> more dynamic sitemap:
>
> - We need a way to assemble a sitemap, pulling in only the snippets that
> the user needs. Eg, most people don't need the community/* support, or
> XML from DTDs, or Forrest's JIRA feed.
Yeah. Seems like blocks to me.
> - We need a way to let users plug in new document types, without hacking
> the original sitemap.
True.
> - More and more, resource-exists actions are creeping into the Forrest
> sitemap.
And make me wonder...
> Right now, we're just piling more stuff into the default sitemap. The
> complexity is already quite intimidating, and discourages users from
> experimenting with the sitemap. Without knowing how to exploit the
> sitemap's flexibility, Forrest is just a frustrating black box.
Yeap, ACK.
> So how do we handle this problem?
>
> I once thought auto-mounted sub-sitemaps could allow us to break up the
> sitemap, but I'm rather skeptical now. Once a request is delegated to a
> subsitemap, it *has* to be handled in that subsitemap. We can't
> speculatively throw in a <map:mount>.
>
> One option is to dynamically create a sitemap.xmap using XSLT, much like
> the Forrestbot creates Ant scripts. Yuck..
Hmmm...
>
> -o0o-
>
>
> Anyway, what this RT is really about is this suggestion: we use a Cocoon
> pipeline to dynamically generate a sitemap, which is then mounted. We
> have a 'primordial' sitemap as follows:
>
> <map:pipeline>
> <map:match pattern="sitemap">
> ...
> </map:match>
> </map:pipeline>
>
> <map:pipeline>
> <map:match pattern="**">
> <map:mount uri-prefix="" src="cocoon:/sitemap" check-reload="no" />
> </map:match>
> </map:pipeline>
>
> The 'sitemap' matcher then assembles a sitemap unique to the current
> project. We can have configuration files which direct the assembly of
> the sitemap, or even inspect the xdocs themselves (if a community/
> directory is present, pull in community/* matchers). This way, we can
> get rid of all those hacky resource-exists checks.
Hacky or not, they are conceptually needed. Your solution still checks
for a resource-exists, but it does it "statically". Your proposal is
tightly binded with the resource-exists thing.
> I don't know how kindly the sitemap engine would take this kind of abuse.
> If it had to regenerate a subsitemap for each request, things would
> certainly be too slow.
Resource-exists "does it" but inside a sitemap. The concept is equivalent.
> At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
> Sources, but I imagine that could be fixed.
Hmmm...
> Thoughts?
Well, as usual I do the "divide et impera" refrain. ;-P
1 - break cocoon sitemap in snippets of functionality
- This is what blocks will be for.
- we can use entity includes now, and this could also
make stefano, who is active now, work faster on blocks ;-P
2 - make it easy for users to add stuff to the pipeline
- this would make it possible for users to add stuff to
the sitemap without exposing it. AOP sitemap.
the point is that Cocoon sitemap should remain
strictly hierarchical for consistency reasons.
So with 1 solved, the main one will be easier to
read and can be completely exposed without fears of
it being too messy.
3 - make a better resource-exists.
- the resource-exists paradigm is part of the easy way
forrest makes it possible to do many things for users.
It's the *same* conceptual thing as CAPs.
what we need is to make it more clever WRT caching and
source indipendent.
4 - make the CAP selector accept an external document for defining
the DTDs, and an action that gets the relevant stylesheets
definitions for the conversion from *DTD 2 DocumentDTD11.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Dynamic sitemaps
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeff Turner wrote:
> On Sat, Mar 01, 2003 at 10:34:20AM +0100, Stefano Mazzocchi wrote:
>
>>Jeff Turner wrote:
>>
>>
>>>At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
>>>Sources, but I imagine that could be fixed.
>>
>>When I hear 'dynamic sitemap', all my FS alarms go off.
>
>
> :) Think of it this way: the resource-exists action is an evil blight on
> sitemaps everywhere. Actions are the equivalent of <if> tasks in Ant.
> The solution I'm proposing is similar to Myrmidon's answer to <if>;
> "unroll" the complexity by adopting a two-step process:
>
> 1) Evaluate all conditionals, and generate a simple static script/sitemap
> 2) Run the generated script/sitemap.
>
> Isn't that cleaner than having switches and if-then-elses that sprout in
> any non-trivial sitemap?
Totally.
> Is there a better solution on the horizon?
Not that I know of. (read below)
>>>Thoughts?
>>
>>This said, why don't you use the XConfTool that Cocoon uses in its build
>>to append pipelines in the sitemap at build time?
>>
>>This is how I'm probably going to do samples build for Cocoon 2.1, it's
>>hacky, I know, but it's a step forward and cocoon blocks in Cocoon 2.2
>>will solve the issues completely.
>
>
> It sounds to me like blocks are to Cocoon what Centipede Cents are to
> Ant: a packaging and assembly system. They do not relieve the need for
> conditional behaviour in sitemaps.
You are right: sitemaps are part of blocks but they don't expose direct
conditionality.
>
>>Please, don't go down the dynamic sitemap path, it's the road to a hell.
>
>
> In Ant's case, the road to hell is paved with Jelly ;)
No shit!
> There are far
> worse solutions than to dynamically build and mount a sitemap with
> Cocoon.
Acknolwedged.
> If you know of any _better_ solutions, I'm all ears.
No, I don't have better solutions.
> --Jeff
>
> (hoping James S isn't reading.. Jelly is cool in the same way Perl is
> cool;)
Right. And I don't think Perl is cool at all. Draw your conclusions. :)
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [RT] Dynamic sitemaps
Posted by Jeff Turner <je...@apache.org>.
On Sat, Mar 01, 2003 at 10:34:20AM +0100, Stefano Mazzocchi wrote:
> Jeff Turner wrote:
>
> >At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
> >Sources, but I imagine that could be fixed.
>
> When I hear 'dynamic sitemap', all my FS alarms go off.
:) Think of it this way: the resource-exists action is an evil blight on
sitemaps everywhere. Actions are the equivalent of <if> tasks in Ant.
The solution I'm proposing is similar to Myrmidon's answer to <if>;
"unroll" the complexity by adopting a two-step process:
1) Evaluate all conditionals, and generate a simple static script/sitemap
2) Run the generated script/sitemap.
Isn't that cleaner than having switches and if-then-elses that sprout in
any non-trivial sitemap? Is there a better solution on the horizon?
> >Thoughts?
>
> This said, why don't you use the XConfTool that Cocoon uses in its build
> to append pipelines in the sitemap at build time?
>
> This is how I'm probably going to do samples build for Cocoon 2.1, it's
> hacky, I know, but it's a step forward and cocoon blocks in Cocoon 2.2
> will solve the issues completely.
It sounds to me like blocks are to Cocoon what Centipede Cents are to
Ant: a packaging and assembly system. They do not relieve the need for
conditional behaviour in sitemaps.
> Please, don't go down the dynamic sitemap path, it's the road to a hell.
In Ant's case, the road to hell is paved with Jelly ;) There are far
worse solutions than to dynamically build and mount a sitemap with
Cocoon. If you know of any _better_ solutions, I'm all ears.
--Jeff
(hoping James S isn't reading.. Jelly is cool in the same way Perl is
cool;)
> --
> Stefano Mazzocchi <st...@apache.org>
> Pluralitas non est ponenda sine necessitate [William of Ockham]
> --------------------------------------------------------------------
>
>
Re: [RT] Dynamic sitemaps
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeff Turner wrote:
> At the moment, <map:mount>'s src attribute doesn't allow for arbitrary
> Sources, but I imagine that could be fixed.
When I hear 'dynamic sitemap', all my FS alarms go off.
> Thoughts?
This said, why don't you use the XConfTool that Cocoon uses in its build
to append pipelines in the sitemap at build time?
This is how I'm probably going to do samples build for Cocoon 2.1, it's
hacky, I know, but it's a step forward and cocoon blocks in Cocoon 2.2
will solve the issues completely.
Please, don't go down the dynamic sitemap path, it's the road to a hell.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [RT] Dynamic sitemaps
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
> match pattern="**.*"
> generate src="cocoon:/{1}" -- referring to the 'input sitemaps' --
> call-pipeline name="{1}" -- don't remember the outcome of the callable
^
duh - must be {2}, of course...
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Dynamic sitemaps
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
> Steven Noels wrote:
>
>> match pattern="**.*"
>> mount src="mountablecontenttypes/{2}" uri-prefix=" "
>> ^
>> don't know what to put in here ---------------------|
> 1) a set of input sitemaps, each of them responsible for bringing a
> specific input source format to a Forrest-processable mid-tier format,
> basically a set of cocoon:/ addressable sources producing mid-tier stuff
>
> 2) a set of output sitemaps, each of them responsible for massaging the
> mid-tier format into the desired output media type (PDF, HTML, and
> whatnot) - the output sitemap is selected by some URI formalism (to not
> mention 'extension' ;-)
match pattern="**.*"
generate src="cocoon:/{1}" -- referring to the 'input sitemaps' --
call-pipeline name="{1}" -- don't remember the outcome of the callable
pipelines discussion anymore --
Does this makes sense at all?
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Dynamic sitemaps
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
> match pattern="**.*"
> mount src="mountablecontenttypes/{2}" uri-prefix=" "
> ^
> don't know what to put in here ---------------------|
did some further thinking....
we have 2 issues at hand when processing and responding a request:
1) sourcetype-aware preparation of a mid-tier format
2) mediatype generation (skinning, PDF and friends)
the idea of using sitemaps is to offer better extensibility to our
end-users, so how about stretching this idea, having:
1) a set of input sitemaps, each of them responsible for bringing a
specific input source format to a Forrest-processable mid-tier format,
basically a set of cocoon:/ addressable sources producing mid-tier stuff
2) a set of output sitemaps, each of them responsible for massaging the
mid-tier format into the desired output media type (PDF, HTML, and
whatnot) - the output sitemap is selected by some URI formalism (to not
mention 'extension' ;-)
Hm.... I'll think some more about this. It could well be I'm just
exploring how loud Stefano's FS bells can ring, of course.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
[RT] Typemaps (Re: [RT] Dynamic sitemaps)
Posted by Jeff Turner <je...@apache.org>.
On Mon, Mar 03, 2003 at 04:33:29PM +0100, Steven Noels wrote:
> Jeff Turner wrote:
>
> >I once thought auto-mounted sub-sitemaps could allow us to break up the
> >sitemap, but I'm rather skeptical now. Once a request is delegated to a
> >subsitemap, it *has* to be handled in that subsitemap. We can't
> >speculatively throw in a <map:mount>.
>
> I haven't spend much thinking on this, but couldn't this bad behaviour
> be caused by the fact we usually map:mount specific 'subdirectories' in
> our URI space:
>
> match pattern="foo/**"
> mount src="mountables/{1}" uri-prefix="mounted/{1}"
>
> Now if we change the thinking to mounting specific media types instead,
> would that help? :
It's a good idea.
> match pattern="**.*"
> mount src="mountablecontenttypes/{2}" uri-prefix=" "
> ^
> don't know what to put in here ---------------------|
>
> so that requests for URI = foo/bar/resourcename.mediatype are routed to
> the sitemap responsible for producing the relevant response for that
> media type.
>
> Of course, this brings the discussion back (gee!) of Marc's infamous
> double extensions, which I strongly despise.
So we can use the same alternative to double extensions, the
SourceTypeAction:
<map:match pattern="**">
<map:act type="sourcetype" src="{0}">
<map:mount uri-prefix="" src="{sourcetype}.xmap" check-reload="yes" />
</map:act>
</map:match>
And allow the SourceTypeAction to be configured with an external XML
file, perhaps one that also assigns 'types' based on file location:
<typemap>
<sourcetype name="faq">
<document-declaration public-id="-//APACHE//DTD FAQ V1.1//EN" />
</sourcetype>
<sourcetype name="community-files">
<location pattern="community/*"/>
</sourcetype>
</typemap>
So all community/* files would be handled by community-files.xmap
With this, the sitemap can define pipelines for _types_ of files,
regardless of where they are located. Instead of:
<map:match pattern="body-faq.xml">
...
<map:match pattern="body-**/faq.xml">
...
<map:match pattern="body-community/**">
...
we'd have:
<map:match pattern="**">
<map:act type="sourcetype" src="{0}">
<map:select type="parameter">
<map:parameter name="parameter-selector-test" value="{sourcetype}" />
<map:when test="faq">
<map:generate src="content/xdocs/{../0}"/>
<map:transform src="library/xslt/howto2document.xsl" label="content" />
</map:when>
<!-- Handle other built-in content types here -->
<map:otherwise>
<!-- Handle user-defined or optional content types -->
<map:mount uri-prefix="" src="{sourcetype}.xmap"/>
</map:otherwise>
</map:select>
</map:act>
<!-- Apply skin to built-in content types -->
<map:call resource="skinit">
<map:parameter name="type" value="site2xhtml" />
<map:parameter name="path" value="{0}" />
</map:call>
</map:match>
That switch is pretty horrible. We could get rid of it with a
SourcetypeMatcher:
<map:match type="sourcetype" pattern="faq">
<map:match pattern="**">
<map:generate src="content/xdocs/{0}"/>
...
</map:match>
</map:match>
<map:match type="sourcetype" pattern="*">
<map:mount uri-prefix="" src="{0}.xmap"/>
</map:match>
How does that sound? With this 'typemap' file, we're introducing a level
of indirection between matchers and pipelines. Instead of matcher ->
pipeline, we have matcher -> type (user-controlled), and then in the
sitemap, type -> pipeline.
--Jeff
> Also, I don't know whether
> this will offer more robustness to the mount concept, nor any enhanced
> modularity. It was just something that came across my mind when reading
> your mails.
>
> I have the tendency to agree with your problem statement, but clearly it
> is one of these border scenarios again, just like reverting the sitemap
> and the link rewriting thing.
>
> Hm.
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
Re: [RT] Dynamic sitemaps
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> I once thought auto-mounted sub-sitemaps could allow us to break up the
> sitemap, but I'm rather skeptical now. Once a request is delegated to a
> subsitemap, it *has* to be handled in that subsitemap. We can't
> speculatively throw in a <map:mount>.
I haven't spend much thinking on this, but couldn't this bad behaviour
be caused by the fact we usually map:mount specific 'subdirectories' in
our URI space:
match pattern="foo/**"
mount src="mountables/{1}" uri-prefix="mounted/{1}"
Now if we change the thinking to mounting specific media types instead,
would that help? :
match pattern="**.*"
mount src="mountablecontenttypes/{2}" uri-prefix=" "
^
don't know what to put in here ---------------------|
so that requests for URI = foo/bar/resourcename.mediatype are routed to
the sitemap responsible for producing the relevant response for that
media type.
Of course, this brings the discussion back (gee!) of Marc's infamous
double extensions, which I strongly despise. Also, I don't know whether
this will offer more robustness to the mount concept, nor any enhanced
modularity. It was just something that came across my mind when reading
your mails.
I have the tendency to agree with your problem statement, but clearly it
is one of these border scenarios again, just like reverting the sitemap
and the link rewriting thing.
Hm.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org