cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Retuning Sitemap Design
Date Wed, 09 Jan 2002 11:13:49 GMT
Vadim Gritsenko wrote:

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

Thanks. I'll try to reply to my best.

> >  - 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.

Very good point. Changing behavior would ruin back-compatibility, so
let's change the grouping:

 direct -> generate, transform, serialize, aggregate, read
 indirect -> act, match, select, mount, redirect

is this any better?

> > 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
> why
> > should we limit it?</note>
> 
> I'm for KISS here also; let's drop these artificial limitations.

Agreed.
 
> > <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":
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=99828709211581&w=2
> and
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=99442091111980&w=2

Hmmmm, did you guys thought about using 'chuncked HTTP'?
 
> >
> > <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
> components.

Ok, good point. Do you see any problem in the future for this?

> > Token Expansion
> > ---------------
> >
> > The expansion syntax follows XSLT attribute-value templates and uses
> the
> > 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)

What about 'all attributes' in the default namespace of elements in the
sitemap namespace?

> > For example, a 'content view' of a resource could return the XML
> content
> > before transformations, or a 'schema view' could return a schema that
> > can be used to validate the content returned in the 'default view'.
> The
> > '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:
>  <map:generate
> src="xmldb:dbxml:///db/document#//*[@xlink:type='simple']/@xlink:href"/>
> (to give an idea...)

Again, very good point, but the real question should be: is the above a
resource view or is another resource entirely?
 
> > Structure Validation
> > --------------------
> >
> > The sitemap should be checked for structure inconsistencies or
> mistakes
> > at load-time.
> >
> > Checks include:
> >
> >  1) all handled requests must pass thru a (generator|serializer) pair
> or
> > a reader.
> 
> What is meant by "all handled requests"? I guess it is requests that
> result in at least one direct component.

It means "all requests that enter a pipeline" and yes, thus result in at
least one direct component touched.

Of course I forgot to say that pipelines without direct components are
illegal.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message