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]
