Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Cocoon's Xinclude behaviour changed with Saxon 8.7.1 - Why?
Date: Tue, 9 May 2006 15:25:42 +0100
Message-ID: <2CA4DE29ACAC6641B440DEEBDD994F2703CF14@sdcexc04.emea.cpqcorp.net>
Thread-Topic: Cocoon's Xinclude behaviour changed with Saxon 8.7.1 - Why?
Thread-Index: AcZzcWIYPQXd/cRdTSuu087PE2ZWLgAARdXw
From: "Fennell, Philip" <philip.fennell@hp.com>
To: <users@cocoon.apache.org>

Jason,

> My guess is that Saxon 8.6 was actually performing the XInclude
inclusions,=20
> not the xinclude transformer, since as far as I know the transformer
doesn't=20
> have a concept of "source document location" and resolves relative
paths from=20
> the sitemap context.  Perhaps something changed with Saxon 8.7.x so
that it=20
> no longer evaluates XIncludes, so now you're seeing the transformer in
action.

Although you say that 'the xinclude transformer, since as far as I know
the transformer doesn't=20
have a concept of "source document location"' that doesn't explain why
both Xalan and Saxon 8.6.x
Where quite happy with paths relative to the source document (the
document being processed by Cocoon)
And only when Saxon 8.7.x is introduced does the context shift to the
Cocoon web application.

A compliant XInclude processor, in the absence of an xml:base attribute,
should resolve URIs relative to the document in which the XInclude
instruction is encountered.

> Perhaps you could handle both cases by using:
> <xi:include href=3D"context:/content/resources/site/login.xml">

I try to avoid where possible using context, cocoon and resource
protocols as they tie the content to this application.

As I cannot provide the whole source for the webapp I am working on I
will endevour to construct a simple test example webapp that illustrates
the problem.

Thanks.


Philip Fennell


-----Original Message-----
From: Jason Johnston [mailto:cocoon@lojjic.net]=20
Sent: 09 May 2006 15:03
To: users@cocoon.apache.org
Subject: Re: Cocoon's Xinclude behaviour changed with Saxon 8.7.1 - Why?

Fennell, Philip wrote:
> I was previously using Saxon 8.6 as the default XSLT processor and I=20
> make use of the XInclude transformer as follows:
>=20
> Sitemap fragment
> ----------------
>=20
> <map:match pattern=3D"content/resources/site/*.html">
>   <map:generate type=3D"request" =
src=3D"content/resources/site/{1}.xml"/>
>   <map:transform src=3D"system/transforms/request2Envelope.xsl"/>
>   <map:transform type=3D"xinclude"/>
>   <map:transform src=3D"interface/transforms/xhtml/screen.xsl"/>
>   <map:serialize type=3D"xhtml"/>
> </map:match>
>=20
>=20
> Source fragment
> ---------------
>=20
> <content id=3D"login">
>   <xi:include href=3D"../../content/resources/site/login.xml">
>     <xi:fallback>login.xml not included.</xi:fallback>
>   </xi:include>
> </content>
>=20
>=20
> Now in this example the xinclude's @href is resolved relative to the=20
> source documents location.

What do you mean by "source documents location"?  What is the source
document?  The src used by the generator?  The XSL?

> However, if I replace Saxon 8.6 with Saxon
> 8.7.1 (I don't know if the '.1' makes a difference) the @href gets=20
> resolved relative to the webapp context. Therefore, I need to use this

> source fragment instead:
>=20
> <content id=3D"login">
>   <xi:include href=3D"content/resources/site/login.xml">
>     <xi:fallback>login.xml not included.</xi:fallback>
>   </xi:include>
> </content>
>=20
>=20
> Is there a reason for this change?
>=20
>=20
> I'm currently using Cocoon 2.1.8 configured to use Saxon as the=20
> default XSLT processor running under Tomcat 5 and Java 1.5.0_05.

My guess is that Saxon 8.6 was actually performing the XInclude
inclusions, not the xinclude transformer, since as far as I know the
transformer doesn't have a concept of "source document location" and
resolves relative paths from the sitemap context.  Perhaps something
changed with Saxon 8.7.x so that it no longer evaluates XIncludes, so
now you're seeing the transformer in action.

Perhaps you could handle both cases by using:
 <xi:include href=3D"context:/content/resources/site/login.xml">

--Jason


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


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