Re: [Kernow-dev] XSLT stack trace

[Florent Georges <lists@fg...>]

Andrew Welch wrote:

> Florent - I've checked in some code for the XSLT sandbox
> to make the output nicer and provide highlighting for the
> compile time errors.

  Great!

> There's a possible bug though

  Thanks for letting me know.  If I have some time, I'll try
to investigate a little bit.  That's a good whish for 2008 BTW:
having more free time !-)

  Regards,

--drkm




















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

Re: [Kernow-dev] XSLT stack trace

[Andrew Welch <andrew.j.welch@gm...>]

Florent - I've checked in some code for the XSLT sandbox to make the
output nicer and provide highlighting for the compile time errors.

There's a possible bug though - if you using incorrect XML then I
think the stack trace code goes into an endless loop, for example use
"<foo/ >"  in the XML pane (as in a gap between / and >) and the
default identity template.

I haven't had time to look into it properly, and probably won't look
at it again for a few days, so I'd thought I'd let you know.

cheers
andrew

Re: [Kernow-dev] XSLT stack trace

[Andrew Welch <andrew.j.welch@gm...>]

On 04/01/2008, Florent Georges <lists@...> wrote:
> > I'm playing around with it now... it's actually surprisingly
> > hard to get it to throw an XPathException instead of a
> > TransformerException...
>
>   I am not sure what you mean.  Actually, you get maybe the exception
> TransformerConfigurationException, as this is what is trown on a
> compilation error.  But as far as I know, all other exceptions (related
> to XSLT) in Saxon are XPathException.

Nearly all of the errors thrown when I was trying to make it fail were
TransformerException's ... such as variable not declared, using ///,
putting an intruction in the wrong place (such as xsl:otherwise not in
xsl:choose).

In then I did select="1 div 0"

>   And that's true that Saxon sees a lot of errors at compile time!  And
> that's damn good.  So you can't only mis-spell some identifiers, that
> should be too easy :-).  You have mostly to write real transformations
> that fail at some point...

Yes - it's surprisingly hard to get it to fail at run time instead of
compile time.


>   The easiest to write IMHO are type errors (@as, builtin function
> parameters, or operator parameters) or error(), depending each time on
> the input tree (so you are sure Saxon has to wait for run time to throw
> the error).

yup... but it even detects:

<xsl:variable name="foo" as="element()">
	<xsl:copy-of select="//@name"/>	
</xsl:variable>

...at compile time, and throws a TransformerException.

You have to fool it by doing:

<xsl:variable name="foo" as="element()">
	<xsl:copy-of select="//@name|//foo"/>	
</xsl:variable>

then you get the output:

Error on line 7 of
file:///C:/Documents%20and%20Settings/awelch/My%20Documents/NetBeansProjects/Kernow/XSLT_in_Kernow:
  XTTE0570: Required item type of value of variable $foo is element();
supplied value has
  item type attribute(name, xs:anyAtomicType)
XTTE0570: Required item type of value of variable $foo is element();
supplied value has item type attribute(name, xs:anyAtomicType)
  in template #saxon:_defaultMode matching "attribute(name,
xs:anyAtomicType)" (at XSLT_in_Kernow:7)
    `-> /root[1]/file[1]/@name
  applied in template #saxon:_defaultMode matching "node()" (at
XSLT_in_Kernow:12)
    `-> /root[1]/file[1]
  applied in template matching "node()" (at XSLT_in_Kernow:12)
    `-> /root[1]
  applied from external application

I might spend some time removing the initial error output at the top
thats output by the default ErrorListener (leaving the nice stack
trace), and then see if I can add highlighting for it on the XSLT
sandbox tab.



-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

Re: [Kernow-dev] XSLT stack trace

[Florent Georges <lists@fg...>]

Andrew Welch wrote:

> This is fantastic Florent - an excellent addition!

  Thanks!

> I'm playing around with it now... it's actually surprisingly
> hard to get it to throw an XPathException instead of a
> TransformerException...

  I am not sure what you mean.  Actually, you get maybe the exception
TransformerConfigurationException, as this is what is trown on a
compilation error.  But as far as I know, all other exceptions (related
to XSLT) in Saxon are XPathException.

  And that's true that Saxon sees a lot of errors at compile time!  And
that's damn good.  So you can't only mis-spell some identifiers, that
should be too easy :-).  You have mostly to write real transformations
that fail at some point...

  The easiest to write IMHO are type errors (@as, builtin function
parameters, or operator parameters) or error(), depending each time on
the input tree (so you are sure Saxon has to wait for run time to throw
the error).

  I still have to write some tests for this new feature, and check if
it is usable for XQuery (for now, I added it to XQuery tabs as well,
but I don't think that works as is...)

  I hope 2008 will be a great year for Kernow ;-)

--drkm























      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

Re: [Kernow-dev] XSLT stack trace

[Andrew Welch <andrew.j.welch@gm...>]

This is fantastic Florent - an excellent addition!

I'm playing around with it now... it's actually surprisingly hard to
get it to throw an XPathException instead of a TransformerException...




On 03/01/2008, Florent Georges <lists@...> wrote:
>   Hi
>
>   I've just commited a new feature that displays the XSLT
> stack trace in case of error.  By XSLT stack trace, I mean
> something like the following:
>
> ERR007: The error message
>   in template matching "xsl:choose" (at style.xsl:54)
>     `-> /xsl:stylesheet[1]/xsl:function[1]/xsl:choose[1]
>   applied in function ns:fun-name #1 (at style.xsl:43)
>   called in template tpl-name (at style.xsl:25)
>     `-> /xsl:stylesheet[1]
>   called in template matching "/" (at style.xsl:16)
>     `-> /
>   applied from external application
>
>   You see that you get where, in the XSLT transform, the
> error occurred: in which template or function, called or
> applied from another template or function, and so on.  The
> path of the current node, if any, is also displayed.
>
>   I wrote a blog entry on this subject a few weeks ago:
>
> http://fgeorges.blogspot.com/2007/11/xslt-stacktrace-with-saxon-9.html
>
>   The code is basically the same, with some improvements
> (the info we have to deal with do not always match the
> lexical representation of the stylesheet, due to Saxon
> optimizations).
>
>   To test it, just make errors :-).  You can use the sample
> stylehseet on the blog entry above and apply it to itself in
> the Single Transform tab.
>
>   What do you think?
>
>   Regards,
>
> --drkm
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       _____________________________________________________________________________
> Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Kernowforsaxon-development mailing list
> Kernowforsaxon-development@...
> https://lists.sourceforge.net/lists/listinfo/kernowforsaxon-development
>


-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

[Kernow-dev] XSLT stack trace

[Florent Georges <lists@fg...>]

  Hi

  I've just commited a new feature that displays the XSLT
stack trace in case of error.  By XSLT stack trace, I mean
something like the following:

ERR007: The error message
  in template matching "xsl:choose" (at style.xsl:54)
    `-> /xsl:stylesheet[1]/xsl:function[1]/xsl:choose[1]
  applied in function ns:fun-name #1 (at style.xsl:43)
  called in template tpl-name (at style.xsl:25)
    `-> /xsl:stylesheet[1]
  called in template matching "/" (at style.xsl:16)
    `-> /
  applied from external application

  You see that you get where, in the XSLT transform, the
error occurred: in which template or function, called or
applied from another template or function, and so on.  The
path of the current node, if any, is also displayed.

  I wrote a blog entry on this subject a few weeks ago:

http://fgeorges.blogspot.com/2007/11/xslt-stacktrace-with-saxon-9.html

  The code is basically the same, with some improvements
(the info we have to deal with do not always match the
lexical representation of the stylesheet, due to Saxon
optimizations).

  To test it, just make errors :-).  You can use the sample
stylehseet on the blog entry above and apply it to itself in
the Single Transform tab.

  What do you think?

  Regards,

--drkm























      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr