cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: Retuning Sitemap Design
Date Wed, 09 Jan 2002 02:44:11 GMT
> From: Stefano Mazzocchi []

<snip type="automatic"/>

> I think it's now time to go back and summarize all this.

Excellent summary! I will try to address some of your questions below.

>  - direct -> generator, transformer, serializer, aggregator, reader
>  - indirect -> action
>  - support -> matcher, selector, mount, redirector

>From the text below, you are assuming that actions do not perform
pipeline routing. As of now, they do this, that's why nesting is 
allowed for actions. If action returns not-null map, body of action
is executed. The question is whether we live it as implemented - then
action should be moved into "support" group; or actions to be changed.

> A pipeline may contain *all* components at the first level.
> <note who="sm">having 'mount' and 'redirect-to' as first level
> components doesn't make really sense, but it doesn't hurt either so
> should we limit it?</note>

I'm for KISS here also; let's drop these artificial limitations.

> <question who="SM">what happens when the client has already received
> part of the request (say during aggregation?)</question>

The discussion had taken place on this, intermediate output stream was 
suggested to avoid "committed response":

> <question>should we allow matchers in aggregator's parts?</question>

I do not see why not. They are very similar to selectors and I suggest
them to be allowed in the same place where selectors are allowed,
and vise verse. Same for actions if they are recognized as support

> Token Expansion
> ---------------
> The expansion syntax follows XSLT attribute-value templates and uses
> curly braces syntax.

Where expansion syntax is allowed? Possible places are:
+ src attribute (generate, transform, mount, ...)
+ uri-prefix attribute (mount)
+ pattern attribute (match)
+ uri attribute (redirect-to)
+ mime-type attribute (read)
+ test attribute (select/when)
+ value attribute (parameter)
+ name attribute (parameter)

> For example, a 'content view' of a resource could return the XML
> before transformations, or a 'schema view' could return a schema that
> can be used to validate the content returned in the 'default view'.
> 'semantic view' might return a resource description document, the
> 'hyperlink view' might return the list of hyperlinks that start from
> that resource, etc...
> Views describe terminating pipeline fragments and must not contain a
> generator since it's the original pipe that performs as generator.

I have a question on this one. Suppose you have quite expensive (cpu,
memory, and non cacheable to top this) generator, and want to invoke 
schema view. Does it mean that this generator will be invoked? Even if
schema of the resource could be as simple as static schema file?
Same for link generator: you might want different generators
to handle default and links views. Example:
+ Default view:
 <map:generate src="xmldb:dbxml:///db/document"/>
+ Links view:
(to give an idea...)

> Structure Validation
> --------------------
> The sitemap should be checked for structure inconsistencies or
> at load-time.
> Checks include:
>  1) all handled requests must pass thru a (generator|serializer) pair
> a reader.

What is meant by "all handled requests"? I guess it is requests that
result in at least one direct component.

Hope my comments do make some sense.


To unsubscribe, e-mail:
For additional commands, email:

View raw message