Steven Noels wrote: > Lars Huttar wrote: > > > I think Peter's email that started this thread was not saying > > that only document() should be used, but rather asking, > > why exclude document()? > > There's a big difference between 'excluding', and 'not > recommending for > specific usecases'. AFAIK, nobody 'excluded' the use of document() in > Cocoon. I think some are just trying to warn people that one > should be > aware of the side-effects caused by the use of this function.
That's where our point of view differs. My impression is that some are opposing the use and support of document() (in Cocoon) in general without considering the cases where it would be useful. E.g. the response to my report of an apparent bug in Cocoon's handling of a document() URI, in the "problem with relative URI in document() in XSLT in Cocoon" thread: > You shouldn't use document() in Cocoon style sheets anyway, for a > variety of reasons, one of them bein problems with caching. > Use <map:aggregate>, XInclude or CInclude instead. When I explained that this was a case where caching was not a problem, and asked for any other reason why I should avoid document() (or, I should add, why I shouldn't expect document() to work according to the XSLT spec), there has been no further response. I can understand why one poster felt that minds are closed on this issue. Obviously not all minds, but... > Whether one likes it or not, we have seen huge performance gains by > minimizing the number of XSLT transformations in a pipeline, > even at the > end of building one-off custom SAXTransformers to replace some XSLT > stylesheets. Cool. > Cocoon is XML-centric, and might be a nice > environment to > do server-side XSLT transformations, but I find it difficult to state > that XSLT (and the document() function) is the panacea for all webapp > development related problems, or more specific aggregation, > or whatelse. Agreed, document() isn't the best tool for all cases. My understanding is that this "crusade" was not to spread the use of document() to all cases, but to rescue it from being bluntly disparaged even in the cases where it's useful, and from being poorly supported. That's my point anyway, i.e., if Cocoon is XML-centric and uses XSLT a lot, it would seem pretty important that document() is handled correctly even if there are cases where it shouldn't be used. > That being said, if anything is missing w.r.t. document() / Source / > caching support in Cocoon (or Xalan!), I'm pretty sure > patches will be accepted gratefully. OK. I guess I should submit a bug report to bugzilla. (That's all I can do.) Lars --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
