Re: [saxon] Cocoon's Xinclude behaviour changed with Saxon 8.7.1 - Why?
|
From: Florent Georges <darkman_spam@ya...> - 2006-05-09 12:15:59
|
Philip Fennell wrote: > The problem is with resolving relative URLs in XInclude > instructions that are being processed by Cocoon I suggest you to post a bug on Cocoon. Maintainers there will be able to say if it is Saxon-related, and if it is to explain the problem here. But again, without more information (XSLT code, Java API used, or whatever), it is quite impossible to identify the problem. Regards, --drkm ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com |
Thread view
|
From: Philip Fennell <philip.fennell@gm...> - 2006-05-09 11:03:01
Attachments:
Message as HTML
|
I was previously using Saxon 8.6 as the default XSLT processor and I make
use of the XInclude transformer as follows:
Sitemap fragment
----------------
<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>
Source fragment
---------------
<content id=3D"login">
<xi:include href=3D"../../content/resources/site/login.xml">
<xi:fallback>login.xml not included.</xi:fallback>
</xi:include>
</content>
Now in this example the xinclude's @href is resolved relative to the source
documents location. 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 resolved
relative to the webapp context. Therefore, I need to use this source
fragment instead:
<content id=3D"login">
<xi:include href=3D"content/resources/site/login.xml">
<xi:fallback>login.xml not included.</xi:fallback>
</xi:include>
</content>
Is there a reason for this change?
I'm currently using Cocoon 2.1.8 configured to use Saxon as the default XSL=
T
processor running under Tomcat 5 and Java 1.5.0_05.
Regards
Philip Fennell
|
|
From: Frans Englich <frans.englich@te...> - 2006-05-09 11:10:34
|
On Tuesday 09 May 2006 11:02, Philip Fennell wrote: > I was previously using Saxon 8.6 as the default XSLT processor and I make > use of the XInclude transformer as follows: [...] > Now in this example the xinclude's @href is resolved relative to the source > documents location. 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 resolved > relative to the webapp context. If I recall correctly, it is correct to resolve against the source document's location, unless one is not standards conformant. This might be of relevance: http://issues.apache.org/bugzilla/show_bug.cgi?id=31600 Cheers, Frans |
|
From: Florent Georges <darkman_spam@ya...> - 2006-05-09 11:24:52
|
Philip Fennell wrote: > Is there a reason for this change? It is hard to help you without more information. What is the faulty XSLT code? Regards, --drkm ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com |
|
From: Philip Fennell <philip.fennell@gm...> - 2006-05-09 11:46:59
Attachments:
Message as HTML
|
Florent, > It is hard to help you without more information. > What is the faulty XSLT code? I think you have missed the point of my question. There is no XSLT problem. The problem is with resolving relative URLs in XInclude instructions that are being processed by Cocoon when Cocoon is using Saxon 8.7.1 as it's XSLT processor. The problem was not present with Xalan and nor was it present with Saxon 8.6, or for that matter 8.5 either. Something has quite definatley changed since I picked-up the latest Saxon jars (8.7.1). If someone realy wants me to package-up a test Cocoon application because they want to, and are willing to, evaluate the problem in context then I will by all means do so. The question still remains: Why has this behaviour occured? -- Regards Philip Fennell On 09/05/06, Florent Georges <darkman_spam@...> wrote: > > Philip Fennell wrote: > > > Is there a reason for this change? > > It is hard to help you without more information. What is the faulty > XSLT code? > > Regards, > > --drkm > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________________= __ > Yahoo! Mail r=E9invente le mail ! D=E9couvrez le nouveau Yahoo! Mail et s= on > interface r=E9volutionnaire. > http://fr.mail.yahoo.com > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > saxon-help mailing list > saxon-help@... > https://lists.sourceforge.net/lists/listinfo/saxon-help > |
|
From: Florent Georges <darkman_spam@ya...> - 2006-05-09 12:15:59
|
Philip Fennell wrote: > The problem is with resolving relative URLs in XInclude > instructions that are being processed by Cocoon I suggest you to post a bug on Cocoon. Maintainers there will be able to say if it is Saxon-related, and if it is to explain the problem here. But again, without more information (XSLT code, Java API used, or whatever), it is quite impossible to identify the problem. Regards, --drkm ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com |
|
From: Pier Fumagalli <pier@be...> - 2006-05-09 12:18:12
Attachments:
smime.p7s
|
On 9 May 2006, at 12:02, Philip Fennell wrote:
> I was previously using Saxon 8.6 as the default XSLT processor and
> I make use of the XInclude transformer as follows:
>
> Sitemap fragment
> ----------------
>
> <map:match pattern="content/resources/site/*.html">
> <map:generate type="request" src="content/resources/site/{1}.xml"/>
> <map:transform src="system/transforms/request2Envelope.xsl"/>
> <map:transform type="xinclude"/>
> <map:transform src="interface/transforms/xhtml/screen.xsl"/>
> <map:serialize type="xhtml"/>
> </map:match>
To debug this, change your sitemap entry to be
<map:match pattern="content/resources/site/*.html">
<map:generate type="request" src="content/resources/site/{1}.xml"/>
<map:transform src="system/transforms/request2Envelope.xsl"/>
<map:serialize type="xml"/>
</map:match>
and run it once with Saxon 8.6 and once with Saxon 8.7.1... If the
two documents resulting are the same, then file a bug on the Cocoon
users mailing list (it's not a Saxon problem), otherwise, it's a
problem with Saxon doing something weird in the XSLT translation (but
I don't think so, seriously).
Pier
|
|
From: Michael Kay <mike@sa...> - 2006-05-09 12:29:34
|
> > and run it once with Saxon 8.6 and once with Saxon 8.7.1... > If the two documents resulting are the same, then file a bug > on the Cocoon users mailing list (it's not a Saxon problem), > otherwise, it's a problem with Saxon doing something weird in > the XSLT translation (but I don't think so, seriously). This problem (unless it's some crazy user error) is almost certainly an interaction problem, relating to the way in which Cocoon is calling Saxon. Generally in such cases I think it works best to create clear reproducible evidence of the problem, and then raise the bug with the "calling" application - Cocoon - who can then raise a bug report on the "called" application if appropriate. Michael Kay http://www.saxonica.com/ |
|
From: Philip Fennell <philip.fennell@gm...> - 2006-05-09 13:31:37
Attachments:
Message as HTML
|
Thank you everyone for your responses. I have also possed the same question on the Cocoon users list but as I have different e-mail addresses for the two list cross-posting has to be done manually. As it seems there is no obvious change that may have contributed to the afore mentioned behaviour I will package-up an example Cocoon webapp with log message etc. and pass this over to the Cocoon list. Thanks again for the input. Regards Philip Fennell On 09/05/06, Michael Kay <mike@...> wrote: > > > > > and run it once with Saxon 8.6 and once with Saxon 8.7.1... > > If the two documents resulting are the same, then file a bug > > on the Cocoon users mailing list (it's not a Saxon problem), > > otherwise, it's a problem with Saxon doing something weird in > > the XSLT translation (but I don't think so, seriously). > > This problem (unless it's some crazy user error) is almost certainly an > interaction problem, relating to the way in which Cocoon is calling Saxon= . > Generally in such cases I think it works best to create clear reproducibl= e > evidence of the problem, and then raise the bug with the "calling" > application - Cocoon - who can then raise a bug report on the "called" > application if appropriate. > > > Michael Kay > http://www.saxonica.com/ > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim= o > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > saxon-help mailing list > saxon-help@... > https://lists.sourceforge.net/lists/listinfo/saxon-help > -- Regards Philip Fennell |