Subject: Re: interpreting trace()'s messages - msg#00038

Previous Message by Date: click to view message preview

RE: Bug in Saxon 7.5.1? java.lang.IllegalStateException

Thanks for this. For some reason it only just appeared in the moderation queue (where all messages from non-members go) - so sorry about the delay. It definitely looks like a bug, and I'll look into it. (Forwards references to functions and global variables have been causing me rather a lot of grief in terms of static type-checking). Michael Kay > -----Original Message----- > From: saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx > [mailto:saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] > On Behalf Of Tim > Sent: 26 May 2003 20:35 > To: saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx > Subject: [saxon] Bug in Saxon 7.5.1? java.lang.IllegalStateException > > > Dear All, > > I believe I have found a bug in Saxon 7.5.1. Saxon generates > an exception if a function is used before it's declared in a > sytlesheet, under certain circumstances. > > Here is the exception report: > > [java] java.lang.IllegalStateException: Static type of > function is not known yet > [java] at > net.sf.saxon.expr.StyleSheetFunctionCall.getCardinality(StyleS > heetFunctionCa > ll.java:102) > [java] at > net.sf.saxon.expr.Expression.isSingleton(Expression.java:285) > > [java] at > net.sf.saxon.expr.PathExpression.getProperties(PathExpression. > java:322) > [java] at > net.sf.saxon.expr.TopLevelExpression.getProperties(TopLevelExp > ression.java:1 > 53) > [java] at > net.sf.saxon.style.XSLVariableDeclaration.fixupReferences(XSLV > ariableDeclara > tion.java:69) > [java] at > net.sf.saxon.style.StyleElement.fixupReferences(StyleElement.java:748) > [java] at > net.sf.saxon.style.XSLStyleSheet.preprocess(XSLStyleSheet.java:522) > [java] at > net.sf.saxon.PreparedStyleSheet.setStyleSheetDocument(Prepared > StyleSheet.jav > a:250) > [java] at > net.sf.saxon.PreparedStyleSheet.prepare(PreparedStyleSheet.java:135) > [java] at > net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFa > ctoryImpl.java > :127) > [java] at net.sf.saxon.Transform.doMain(Transform.java:391) > [java] at net.sf.saxon.Transform.main(Transform.java:63) > [java] Fatal error during transformation: Static type of > function is not known yet > > The source xml file appears to be irrelevant, for example a > completely empty xml file produces the exception. Here is a > (silly but short) stylesheet that produces the error: > > <?xml version="1.0" encoding="utf-8"?> > > <xsl:stylesheet > xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > > xmlns:ns="namespace" > > version="2.0"> > > <xsl:template match="ns:link"> > <xsl:variable > name="variable" > select="ns:function()/*"/> > <xsl:copy-of select="$variable"/> > </xsl:template> > > <xsl:function name="ns:function"> > <xsl:sequence > select="'string'"/> > </xsl:function> > > </xsl:stylesheet> > > The use of a variable appears to be important, as does the > attempt to select nodes from the function result. > > I'm able to reproduce the error using Java 2 SDK 1.4.0_01 and > Java 1.4.1_02, and Saxon 7.5.1 (and 7.5). 7.4 does not > generate the exception (with xsl:sequence replaced with xsl:result). > > If the function is declared before the template in the > stylesheet, the exception is not generated. > > Kind regards, > > > > Tim Jervis > http://timjervis.com/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The best thread debugger on the planet. Designed > with thread debugging features you've never dreamed of, try > TotalView 6 free at www.etnus.com. > _______________________________________________ > saxon-help mailing list > saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/s> axon-help > ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Next Message by Date: click to view message preview

RE: resolve-uri 7.5.1 and xml:base

David, resolving a relative URI against a base URI is what happens every time you use <a href="some.html"> in an HTML document. The relative URI is interpreted as being relative to some base URI, which by default is the URI of the HTML page containing the reference. Sometimes you want to resolve relative to a different base URI, and that's what this function enables you to do. In XSLT 1.0 the document() function does this behind the scenes, but people wanted it made available as a primitive to give users more control. As Trevor pointed out, resolving URIs is a syntactic manipulation of the URIs as strings. It has nothing to do with any real resources that the URIs might identify. Michael Kay > -----Original Message----- > From: saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx > [mailto:saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] > On Behalf Of > David.Pawson-3xYO7gc8JOj10XsdtD+oqA@xxxxxxxxxxxxxxxx > Sent: 11 June 2003 15:42 > To: tcn-T83dHKhaxTMqdlJmJB21zg@xxxxxxxxxxxxxxxx; > saxon-help@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: [saxon] resolve-uri 7.5.1 and xml:base > > > Hi Trevor. > > > From: Trevor Nash [mailto:tcn-T83dHKhaxTMqdlJmJB21zg@xxxxxxxxxxxxxxxx] > > > URI resolution is purely a matter of string manipulation, > it isn't a > > searching mechanism. As Oliver pointed out, the 'sgml' is being > > dropped because it is being interpreted as a file name - if its a > > directory you need the trailing slash. > OK, I'm happy with that. > > > > resolve-uri will never insert the files/xslt2 bit because > it doesn't > > know about file systems or how to search them. Think about > it: what > > if there was also a file c:/sgml/other-files/xslt2/test1.xsl. Then > > what string would be returned?? > > So just what is it 'resolving'? > My catalog resolver maps from either an fpi to a uri, > or from a uri to a uri (most to a local file). > > I guess I do expect it to comprehend a local file system. > > Is it just me that finds it incomprehensible? > What use is it? > > As of 7.5.1 > > <xsl:value-of select="resolve-uri('./test1.xsl','file://c:/')"/> > > returns file://c/sgml/test1.xsl > > and I see no relationship that is of use to me. > > Is it another one of Mikes 'dump it' functions? > > regards DaveP > > - > > NOTICE: The information contained in this email and any > attachments is > confidential and may be legally privileged. If you are not the > intended recipient you are hereby notified that you must not use, > disclose, distribute, copy, print or rely on this email's content. If > you are not the intended recipient, please notify the sender > immediately and then delete the email and any attachments from your > system. > > RNIB has made strenuous efforts to ensure that emails and any > attachments generated by its staff are free from viruses. However, it > cannot accept any responsibility for any viruses which are > transmitted. We therefore recommend you scan all attachments. > > Please note that the statements and views expressed in this email > and any attachments are those of the author and do not necessarily > represent those of RNIB. > > RNIB Registered Charity Number: 226227 > > Website: http://www.rnib.org.uk > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The best thread debugger on the planet. Designed > with thread debugging features you've never dreamed of, try > TotalView 6 free at www.etnus.com. > _______________________________________________ > saxon-help mailing list > saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/s> axon-help > ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Previous Message by Thread: click to view message preview

RE: interpreting trace()'s messages

> > Then (the current version of) trace() might not be what I want. > > 1. I want to get information about a certain sequence at a certain > point, which may not be the same point where I use it. > > 2. I need the information provided by trace(), but I want to > decide on > my own if I print this string or not. The function or element I want > should not print anything, but only return a string. > > 3. I only want to see those values when I debug the XSLT, not > when I or > others run it. > So I need to be able to enclose everything that prints out > debug messages in > <xsl:if test="$debug" ... > . > I would do: <xsl:for-each select="trace($x, 'x')"> <xsl:value-of select="''"/> </xsl:for-each> Because I happen to know that Saxon won't currently optimize this out of existence. There is an intrinsic problem with trace() that it will show you the effect of executing optimized code, which may be totally incomprehensible. Michael Kay ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Next Message by Thread: click to view message preview

Re: interpreting trace()'s messages

On Wed, 11 Jun 2003 17:09:02 +0200, Tobias wrote: >> There is an intrinsic problem with trace() that it will show you the >> effect of executing optimized code, which may be totally >> incomprehensible. > > >This is one more proof that (the current) trace() does not satisfy my >requirements. Or, proof that functions with side effects in a functional language are a bad idea? Trevor Nash Melvaig Software Engineering Limited voice: +44 (0) 1445 771 271 email: tcn-T83dHKhaxTMqdlJmJB21zg@xxxxxxxxxxxxxxxx web: http://www.melvaig.co.uk ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5