Saxon

Legacy ID: #5104709 Legacy Poster: Michael Kay (mhkay)

Thanks for reporting this. I'll fix the stack trace so if the line number is unknown then it doesn't attempt to display it. Saxon tries quite hard to maintain line number information for all expressions even throught optimizer rewrites, but it seems to have failed on this occasion. If you can supply the source code to illustrate the problem then I'll be happy to look at fixing the problem for this instance - but I'm afraid it has to be done on a case-by-case basis. Unfortunately the new ability to produce stack traces on dynamic errors will expose more cases where the location information isn't being properly retained. Michael Kay http://www.saxonica.com/

Legacy ID: #5105996 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

Ah, I found the reason. Due to internal details of calling application, primary stylesheet is passed as DocumentInfo instance: DocumentInfo document = ... ... = factory.newTemplates(document); The document has a correct base uri and line info. According to the stack stylesheet is being built using DocumentSender, which does not provide line info: DocumentImpl.setLineAndColumn(int, int, int) line: 220 XSLStylesheet(ElementImpl).setLocation(String, int, int) line: 76 StyleNodeFactory.makeElementNode(NodeInfo, int, int, AttributeCollectionImpl, int[], int, LocationProvider, int, int) line: 93 TreeBuilder.startContent() line: 211 UseWhenFilter.startContent() line: 163 StartTagBuffer.startContent() line: 222 StylesheetStripper(ProxyReceiver).startContent() line: 166 CommentStripper(ProxyReceiver).startContent() line: 166 TinyElementImpl.copy(Receiver, int, boolean, int) line: 342 TinyDocumentImpl.copy(Receiver, int, boolean, int) line: 293 DocumentSender.send(Receiver) line: 54 Sender.sendDocumentInfo(NodeInfo, Receiver) line: 278 Sender.send(Source, Receiver, boolean) line: 177 Sender.send(Source, Receiver) line: 50 PreparedStylesheet.loadStylesheetModule(Source, StyleNodeFactory) line: 231 PreparedStylesheet.prepare(Source) line: 162 TransformerFactoryImpl.newTemplates(Source) line: 139 ... In contrast <xsl:include/> is handled differently. As result included stylesheets have line info, and primary one has not. Thanks.

Legacy ID: #5106200 Legacy Poster: Michael Kay (mhkay)

Thanks. I've added a TODO to the code to configure the document rebuild in this case to retain line numbers if they are present in the source document.

Legacy ID: #5124516 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

More on error trace. Whenever I access context item from the function I receive an error: ---- Error at xsl:function on line 558 column 58 of generate-sql-statements.xslt: XPDY0002: Axis step attribute::attribute(record-owner, xs:anyAtomicType) cannot be used here: the context item is undefined ---- Such errors always, as far as I've noticed, point to a xsl:function instruction, whereas the origin is in the function's body. Thanks.

Legacy ID: #5126751 Legacy Poster: Michael Kay (mhkay)

>Error at xsl:function on line 558 Thanks for pointing this out. There's code (at StyleElement.compileError()) that tries to promote the location of static "semantic" errors from the XPath expression level to the XSLT instruction level, presumably so that the location can be given in the form "Error at xsl:value-of ....". Unfortunately in this case (and in fact in all cases where the error is detected during the second phase of type checking) it's promoting it too far. Changing this code could have adverse effects on error reporting elsewhere, so it needs to be done with care. But I'll see what can be done.