Michael Wechner wrote: > > For example, suppose you have something like this > > > > <blah> > > <include xmlns="http://www.w3.org/xinclude/2000"; src="blah.inc"/> > > <include xmlns="http://apache.org/cocoon/include"; src="blah.inc"/> > > </blah> > > > > > the first tag should *not* be processed by Cocoon, even by an > > 'including' transformer. > > Please apologize if my question might be stupid, but what reason > could there be not to process the first XInclude on the server, but > to process the second on the server?
Performance and scalability. If we had client-side Xinclude, you could have parts of your HTML pages xincluded and therefore cached, proxied and so on, just like you do with images. > I think it's very confusing if Cocoon would be using another namespace > for XInclude than the one defined by w3. In that case, you are forcing people *not* to be able to use xinclude on client side and cocoon on the server side. Sure, the need is not evident now that nobody implements xinclude on the client side, but as soon as somebody does (and I think mozilla might the first one), you'll see emerging needs for having client side *and* server side inclusion. Without different namespaces, this is simply not possible. > If you want your example work as you describe it, then I think > you can still do it the other way around, which means the initial > XML would be as follows: > > <blah> > <bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"; > href="blah.xml"/> > <xi:include xmlns="http://www.w3.org/2001/XInclude"; href="blah.xml"/> > </blah> > > then you send this XML through the XIncludeProcessorTransformer of > Cocoon and receive something like > > <blah> > <bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"; > href="blah.xml"/> > <blah> > blabla > </blah> > </blah> > > then you send this XML through some XSLT (Transformer) which is > replacing the bi:include by the xi:include > > <blah> > <xi:include xmlns:bi="http://www.w3.org/2001/XInclude"; href="blah.xml"/> > <blah> > blabla > </blah> > </blah> > > and then you send (serialize) it to the client. > > Or did I misunderstand your example? No, this is correct, but you require a stylesheet to come up with namespace rewriting (which is a hard thing to learn for users, in my experience). Having the ability to specify what namespace to react upon, is, IMO, a better solution. > > > > So, IMO, the best long term solution would be: > > > > 1) deprecate both XIncludeTransformer and CIncludeTransformer > > 2) change CIncludeTransformer to IncludeTransformer > > 3) make IncludeTransformer work just on a cocoon-specific namespace > > > > what do you think? > > If you don't want to decide what namespaces, elementnames, > attributenames you want to choose for the future, IMO it makes > sense to make the IncludeTransformer configurable with the regard to > the "names", such that it can process all types of "includes" as for > instance <xsl:include, <xi:include, xlink:href, etc. Yes, that makes sense. > One Cocoon specific remark: > I really learned to appreciate the "cocoon:" protocol supported by > the current XIncludeTransformer. But it is a little bit "dangerous", > because nobody else is supporting this protocol yet. In case you > want to replace Cocoon by something else ;-) you will run into troubles > because it won't work anymore. Therefore IMO it makes a lot of sense > to use another namespace if you use the "cocoon:" protocol together > with XInclude. But concerning the code base I think it makes a lot of > sense to merge the code of the exsting ones. I agree. > I am currently refactoring my own XIncludeProcessor, and as soon > as it is more "cocoonish" I will post it as a patch as Ivelin was > suggesting it. Cool, thanks. > Maybe it helps someone. > > Thanks > > Michael > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- 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]
