Re: [XSLT2] debugging XSLT apps; getting information about items and sequences

Kay, Michael wrote:

> Perhaps what would best meet your requirements is something like
> 
> <xsl:message select="$parent">parent</xsl:message>


I can't really not know, since you don't say what this would do.

But it seems it couldn't satisfy my requirements: My main requirement is 
to get an informative string, which I can print out or write to a log, 
store or process further.

That's way I suggested

<xsl:message>
   <xsl:inspect select="$parent"/>
   <xsl:inspect select="$children"/>
</xsl:message>


> However, all attempts to define debugging and trace output suffer from the
> same problems: the more the stylesheet is optimized, the less meaningful the
> output is going to be.


I suspect that there is at least one possible solution. Many programming 
languages offer useful inspection facilities.

Currently for example I have

<xsl:function name="jcs:first_valid">
   <xsl:param name="parent"/>
   <xsl:param name="children"/>
   <xsl:message>
     <xsl:copy-of select="trace($parent,'parent')"/>
     <xsl:copy-of select="trace($children,'children')"/>
   </xsl:message>
   ...

I need to get information about the values that are received by the 
function. It would be very useful to provide this information to the 
developer, even when optimizing eg recursing functions.


> Clearly, since both xsl:message and fn:trace() have the side-effect of
> writing the value to some diagnostic stream, you don't want to use fn:trace
> inside xsl:message, since you will then get the output twice. They are
> alternatives, not facilities to be used in conjunction.


As I said I want a facility which returns a string, and does not print 
out anything.

Thus far, none of the suggested alternatives were better (more useful == 
informative) than what I already had:

   <xsl:message>
     <xsl:copy-of select="trace($parent,'parent')"/>
     <xsl:copy-of select="trace($children,'children')"/>
   </xsl:message>


> My personal view (my company's view, in fact) is that diagnostic
> capabilities should be outside the scope of the specification: see
>  http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0091.html


I know, and I disagree.

But I could live with saxon:inspect (etc).
(... offering what I describe in
http://lists.w3.org/Archives/Public/public-qt-comments/2003Jun/0098.html )

Tobi

-- 
http://www.pinkjuice.com/

Received on Thursday, 12 June 2003 18:04:20 UTC