Re: [xml-dev] Using Saxon 9 as a Schematron 1.5 back end

[Henri Sivonen <hsivonen@iki.fi>]

On Jan 21, 2008, at 13:48, John Snelson wrote:

> An XSLT 2.0 processor is also a perfectly good XSLT 1.0 processor  
> for the large majority of use cases. The incompatibilities between  
> XSLT 2.0 in backwards compatible mode and XSLT 1.0 are detailed here:
>
> http://www.w3.org/TR/xslt20/#incompatibilities

It says "Backwards compatible behavior also affects the results of  
certain XPath expressions, as defined in [XPath 2.0]."

That spec has this: "The list below contains all known areas, within  
the scope of this specification, where an XPath 2.0 processor running  
with compatibility mode set to true will produce different results  
from an XPath 1.0 processor evaluating the same expression, assuming  
that the expression was valid in XPath 1.0, and that the nodes in the  
source document have no type annotations other than xs:untyped and  
xs:untypedAtomic."

Hmm. So the backwards compat mode isn't quite a backwards compat mode.  
The differences do appear mostly harmless, though.

On Jan 21, 2008, at 15:38, Michael Kay wrote:

>> Should I put my effort into patching Saxon 6 or 9? That is,
>> can I use Saxon 9 without breaking the semantics of
>> Schematron 1.5 schemas that use XPath 1.0 queries?
>
> I think that if you run XPath 2.0 in "backwards compatible mode" the
> remaining incompatibilities with XPath 1.0 can almost certainly be  
> safely
> ignored. If users run into these then they are doing something  
> fairly weird
> - either unintentionally, or deliberately to test the known  
> compatibility
> corner cases. So I would definitely work with Saxon 9.

OK. Does version="1.0" on the XSLT root element enable the compat  
mode? (It seems like an obvious guess but the docs don't appear to  
say--or if they do, it is hard to find.)

> Having said that, there's a reason Saxon doesn't give you column  
> numbers,
> which is that the column number reported by the SAX parser is  
> usually not
> very meaningful. Both the line number and column number typically  
> reflect
> the position of the ">" at the end of the start tag. You're  
> therefore very
> likely to be reporting an error at column 68 when the actual error  
> is at
> column 15, and I've generally taken the view that it's better to  
> report
> nothing at all than to get it quite so badly wrong. The only case  
> where
> column numbers might be useful is where the XML is all on one line.
> Unfortunately text editors don't handle that case well anyway, so  
> knowing
> that an error is at column 14763 of line 1 doesn't usually make it  
> much
> easier to find.

In my case, I control both the SAX parser and the handler that  
receives the locations the validation engines. This way, I've managed  
to implement error highlighting in the Validator.nu UI. So I have a  
case for wanting to get the column locations that I put in back from  
the XSLT engine. (To the point that I feel I need to patch Saxon in  
order to switch to it or otherwise I'd regress the user experience  
noticeably.)

> (Saxon's retention of line numbers is designed primarily for reporting
> errors in stylesheets and schema documents, not in instance  
> documents. For
> instance documents, it might also be useful to retain the position
> information for text nodes - Saxon currently retains it only for  
> elements.)


I'm primarily interested in instance document locations. :-) However,  
with typical Schematron rules, getting the locations for element nodes  
is the most important thing.

Thank you.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/