On Thursday 27 June 2002 06:40 am, Stefano Mazzocchi wrote: > Counterexamples: > > 1) FileGenerator, where the schema of the output is bound to the > resource being parsed and it's available at runtime only.
But what if there was something like: <map:generate type="file" src="cocoon://myfile.xml"> <map:output-schema src="cocoon://myfile.xsd"/> </map:generate> > 2) XSLTTransformer, where the transforming instructions (thus the schema > constraints) are bound to the stylesheets and not the code that > interprets it. (Things change with XSLTC which is able to compile > stylesheets, but XSLTC will never be Avalon-aware anyway). And: <map:transform type="xslt" src="cocoon://mytransform.xsl"> <map:input-schema src="cocoon://mytransform-input.xsd"/> <map:output-schema src="cocoon://mytransform-output.xsd"/> </map:transform> Upon further dwelling, doing this at the pipeline level would probably be overkill, but for the blocks you have been working on, it might make sense at the block entry/exit points. > Still, I have the feeling that Cocoon should not use the same container > to handle sitemap components and the other more general components. I agree. Cocoon's sitemap is a special case and will require a specialized container. -pete -- peter royal -> [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
