cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivelin Ivanov <ive...@apache.org>
Subject Re: XInclude Transformer vs CInlude Transformer
Date Fri, 14 Jun 2002 03:02:41 GMT

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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 



-- 

-= Ivelin =-


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message