Your solution sounds fine to me too.
Michael Wechner wrote: > > > Stefano Mazzocchi wrote: > >> Mattam wrote: >> >>> Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]: >>> >>> | >>> | Two almost identical transformers are confusing me. >>> | What is the difference between the two? >>> | Should one be deprecated? >>> | >>> | I'd vote for the one which implements the W3C XInclude spec closest. >>> | Maybe it should take the best of the other one. >>> | >>> >>> CInclude allows cocoon:/ protocol, and XInclude tends to be a strict >>> implementation of the standard. Maybe keeping only XInclude while >>> allowing the cocoon:/ protocol (with a switch?) would be the better. >>> >> >> I agree, having both is highly confusing. Moreover, I think that we >> should *not* be using the XInclude namespace on the server side because >> we could get collisions in the future for browsers implementing XInclude >> on the client side. >> >> 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? > > I think it's very confusing if Cocoon would be using another namespace > for XInclude than the one defined by w3. > > 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? > > >> >> 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. > > 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 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. > > Maybe it helps someone. > > Thanks > > Michael > > >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > -- -= Ivelin =- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
