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. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
