[saxon] Saxon CE, result-document and Xpaths‏

[Tom T]

The Saxon CE documentation states: 
> The form <xsl:result-document href="?select=//table[1]/td"> where > the select parameter is an XPath expression that is evaluated relative > to the root of the HTML document. 
I am using XSLT to populate an HTML page. When I execute such a result-document command from my <xsl:template match="/"> context nothing gets produced. 
>

[Martin Honnen]

Tom T wrote:
>
> The Saxon CE documentation states:
>> The form<xsl:result-document href="?select=//table[1]/td"> where> the select parameter is an XPath expression that is evaluated relative> to the root of the HTML document.
> I am using XSLT to populate an HTML page. When I execute such a result-document command from my<xsl:template match="/"> context nothing gets produced.
>

[Tom T]

> although the path //table[1]/td is a poor choiceFair point, I have actually tried it with a few other XPaths, all to no avail. I just used this as an example as that was the example provided in the documentation.> I tried some simple examples like
>
> <xsl:result-document href="?select=//p">Paragraph content created 
> by XSLT.</xsl:result-document>
> 
> and
> 
> <xsl:result-document href="?select=//table[1]/tbody/tr/td">table 
> cell content created by XSLT</xsl:result-document>
> 
> and they worked for me with Firefox 6 and Opera 11.5.I tried the first one and nothing comes out in Firefox 3 and Chrome 14 (perhaps I should upgrade Firefox...). I do not get any kind of alert box for chrome though, just nothing is produced.

[Martin Honnen]

Tom T wrote:
>
>> although the path //table[1]/td is a poor choiceFair point, I have actually tried it with a few other XPaths, all to no avail. I just used this as an example as that was the example provided in the documentation.> I tried some simple examples like
>>
>> <xsl:result-document href="?select=//p">Paragraph content created
>> by XSLT.</xsl:result-document>
>>
>> and
>>
>> <xsl:result-document href="?select=//table[1]/tbody/tr/td">table
>> cell content created by XSLT</xsl:result-document>
>>
>> and they worked for me with Firefox 6 and Opera 11.5.I tried the first one and nothing comes out in Firefox 3 and Chrome 14 (perhaps I should upgrade Firefox...). I do not get any kind of alert box for chrome though, just nothing is produced.

Initially I simply tried to load the HTML and the XSLT and Saxon CE
script files from the file system and then Chrome would not show
anything in the browser window but the error console would show script
security errors which seemed to be related to Saxon (or maybe GWT)
setting up an iframe with additional script. Opera also that way had
warnings in the error console that suggested that XMLHttpRequest loading
directly from the file system was not allowed. And IE 9 anyway by
default disables any script in HTML loaded from the local file system.

Therefore I changed to setting up anything on my local web server to
ensure all files are loaded over HTTP and not directly from the file system.

So that might be one reason for Chrome not showing anything, if you
tried to load files from the file system.

Upgrading FF to the current version is also worth a try.




--

Martin Honnen --- MVP Data Platform Development
http://msmvps.com/blogs/martin_honnen/

[Philip Fearon]

An update on result-documents and XPaths:

Saxon-CE Alpha 0.4 (released on Friday) fixed two known issues related to
this (#29 and #30 in the Alpha 0.4 issues list). However, since then, Alpha
0.4.1 has been released to fix a further issue (#31) identified with
Simon's help.

It should now be possible to use XPaths with result documents. Please let
us know if there are further issues with this.

Thanks,

Phil

Phil Fearon
Saxonica



On Fri, Sep 23, 2011 at 4:43 PM, Martin Honnen <***@arcor.de>wrote:

> Tom T wrote:
> >
> >> although the path //table[1]/td is a poor choiceFair point, I have
> actually tried it with a few other XPaths, all to no avail. I just used
> this as an example as that was the example provided in the documentation.>
> I tried some simple examples like
> >>
> >> <xsl:result-document href="?select=//p">Paragraph content created
> >> by XSLT.</xsl:result-document>
> >>
> >> and
> >>
> >> <xsl:result-document href="?select=//table[1]/tbody/tr/td">table
> >> cell content created by XSLT</xsl:result-document>
> >>
> >> and they worked for me with Firefox 6 and Opera 11.5.I tried the first
> one and nothing comes out in Firefox 3 and Chrome 14 (perhaps I should
> upgrade Firefox...). I do not get any kind of alert box for chrome though,
> just nothing is produced.
>
> Initially I simply tried to load the HTML and the XSLT and Saxon CE
> script files from the file system and then Chrome would not show
> anything in the browser window but the error console would show script
> security errors which seemed to be related to Saxon (or maybe GWT)
> setting up an iframe with additional script. Opera also that way had
> warnings in the error console that suggested that XMLHttpRequest loading
> directly from the file system was not allowed. And IE 9 anyway by
> default disables any script in HTML loaded from the local file system.
>
> Therefore I changed to setting up anything on my local web server to
> ensure all files are loaded over HTTP and not directly from the file
> system.
>
> So that might be one reason for Chrome not showing anything, if you
> tried to load files from the file system.
>
> Upgrading FF to the current version is also worth a try.
>
>
>
>
> --
>
> Martin Honnen --- MVP Data Platform Development
> http://msmvps.com/blogs/martin_honnen/
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>

[Michael Kay]

>IE 9 and Chrome 14 however always throw up an alert box saying that
the stylesheet loading resulted in a status code 400 (Exact error
message in Chrome 14 is "Failed to load XSLT stylesheet null: (String):
HTTP request for http://localhost/someDir/someSubDir/test2011092301.xsl
failed with status code: 400"). For reasons I don't understand Firefox
fails with the same message as soon as I use a result-document
href="?select=" path to a non-existing element. With Opera the
stylesheet execution continues to work, result-document pointing to non
existing elements seem to be simply ignored. So as far as I can tell,
the documentation example with result-document
href="?select=//table[1]/td" shows the right syntax, although the path
//table[1]/td is a poor choice as with current HTML documents a "td"
element will never be a child of a "table" element. Even
//table[1]/tr/td will not work as HTML parsers always add a "tbody"
element in the DOM.


Yes, this could be the source of the problem.

Michael Kay
Saxonica

[Simon Pepping @ Home]

For me this works in the latest firefox (iceweasel 8.0) when I use the below
statements in the initial template, and I do not use a data-source. When I
add a data-source (even though my template does not really access it),
nothing is added to the html nodes.

I also have this problem: When I write

<xsl:call-template name="lut">
<xsl:with-param name="dates" select="//atom:updated |
ixsl:page()//time[@id='lut']/@datetime"/>
</xsl:call-template>

all selected nodes are in the parameter, but when I write:

<xsl:apply-templates select="time[@id='lut']"/>

and in that template:

<xsl:for-each select="./@datetime | //atom:updated">

the //atom:updated nodes are missing from the node sequence. These two cases
share a thing: It is impossible to use an XPath expression into the HTML
DOM when one is in the data source tree, and vice versa.

Simon Pepping


Martin Honnen-2 wrote:
>
>
> I tried some simple examples like
>
> <xsl:result-document href="?select=//p">Paragraph content created
> by XSLT.</xsl:result-document>
>
> and
>
> <xsl:result-document href="?select=//table[1]/tbody/tr/td">table
> cell content created by XSLT</xsl:result-document>
>
> and they worked for me with Firefox 6 and Opera 11.5.
>
>

--
View this message in context: http://old.nabble.com/Saxon-CE%2C-result-document-and-Xpaths%E2%80%8F-tp32524944p32930377.html
Sent from the saxon-help mailing list archive at Nabble.com.

[Michael Kay]

On 07/12/2011 19:07, Simon Pepping @ Home wrote:
> For me this works in the latest firefox (iceweasel 8.0) when I use the below
> statements in the initial template, and I do not use a data-source. When I
> add a data-source (even though my template does not really access it),
> nothing is added to the html nodes.
>
> I also have this problem: When I write
>
> <xsl:call-template name="lut">
> <xsl:with-param name="dates" select="//atom:updated |
> ixsl:page()//time[@id='lut']/@datetime"/>
> </xsl:call-template>
>
> all selected nodes are in the parameter, but when I write:
>
> <xsl:apply-templates select="time[@id='lut']"/>
>
> and in that template:
>
> <xsl:for-each select="./@datetime | //atom:updated">
>
> the //atom:updated nodes are missing from the node sequence. These two cases
> share a thing: It is impossible to use an XPath expression into the HTML
> DOM when one is in the data source tree, and vice versa.
>
> Simon Pepping
>
In the first case, xsl:with-param takes care to select each branch of
the union within its own tree: //atom:updated is selected in the tree
containing the context node (presumably, the source XML document), while
time[@id='lut'] is selected in the HTML tree (ixsl:page()).

In the second case, you make no such distinction. Presumably the
select="time[@id='lut']" is selecting within the HTML tree, in which
case //atom:updated is also selecting within the HTML tree. You need to
bind a global variable to the source document

<xsl:variable name="source" select="/"/>

and then use $source//atom:updated.

This problem, incidentally, is quite unrelated to the thread that you
have quoted. We're aware of problems with select expressions in
xsl:result-document and we're close to releasing a new alpha version
that fixes this and other problems.

Regards,

Michael Kay
Saxonica

[Philip Fearon]

Though this thread is about result-documents and XPaths (which was
fixed in A0.4.1), it's worth mentioning here that an HTTP 400 error
will also occur (as described below) when IIS 7 is being used as the
Web Server.

The IIS 7 / HTTP 400 problem is caused by Saxon-CE setting the
'If-Modified-Since' value in the HTTP request header when loading the
xsl file, this will be fixed in the next Saxon-CE release.

Phil

On Fri, Sep 23, 2011 at 1:38 PM, Martin Honnen <***@arcor.de> wrote:
>
>
> I tried some simple examples like
>
>       <xsl:result-document href="?select=//p">Paragraph content created
> by XSLT.</xsl:result-document>
>
> and
>
>     <xsl:result-document href="?select=//table[1]/tbody/tr/td">table
> cell content created by XSLT</xsl:result-document>
>
> and they worked for me with Firefox 6 and Opera 11.5.
>
> IE 9 and Chrome 14 however always throw up an alert box saying that the
> stylesheet loading resulted in a status code 400 (Exact error message in
> Chrome 14 is "Failed to load XSLT stylesheet null: (String): HTTP
> request for http://localhost/someDir/someSubDir/test2011092301.xsl
> failed with status code: 400").
>