> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
<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 why > 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": 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 > > <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. > 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) .... > 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...) > 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. Hope my comments do make some sense. Regards, Vadim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
