Re: Added support for Saxon 9.7 to Calabash

> 1/ Schematron validation fails (testValidsch001 to testValidsch005)
> 2/ Default collection not set (testXquery006 and testXslt2003)
> 3/ Base URI on secondary documents (testXslt006 and testXslt2002)

As I said, 1/ is fixed in the following commit:
http://github.com/fgeorges/xmlcalabash1/commit/d8c9dbcb3da7782

Thanks to Mike's answer to my email, I could fix 2/ in the commit:
https//github.com/fgeorges/xmlcalabash1/commit/ca8532514bf375d

On 3/, I could reproduce the issue in a standalone example, and I sent
it to Saxon's list: http://saxon.markmail.org/thread/33nknzl77x7nn5sl.
Not sure what's the answer on this one.

So all 717 tests pass on the branch saxon97, except those 2 (related
to the base URI, as described in the above thread on Saxon's list):

- testXslt006
- testXslt2002

Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/


On 6 November 2016 at 16:10, Florent Georges wrote:
> Hi,
>
> A quick update on this.  To summarize, I created a branch to support
> Saxon 9.7: https://github.com/fgeorges/xmlcalabash1/commits/saxon97,
> where there were still the following tests failing:
>
> 1/ Schematron validation fails (testValidsch001 to testValidsch005)
> 2/ Default collection not set (testXquery006 and testXslt2003)
> 3/ Base URI on secondary documents (testXslt006 and testXslt2002)
>
> On 1/, I was puzzled with the fact Schematron validation was requiring
> SaxonEE.  Actually, the test used for detecting whether "schema-
> awareness" was required (in ValidateWithSCH.java, line 96) is not
> correct anymore.  In Saxon 97, the method getSchemaType() does not
> return null anymore, but "xs:untyped".  The change I made is
> compatible with both version (if null, or xs:untyped, then it is not
> SA): http://github.com/fgeorges/xmlcalabash1/commit/d8c9dbcb3da7782.
>
> So these 5 tests pass now.
>
> On 2/, I could actually not make the simple query "collection()" work
> on Saxon HE 9.7, using s9api.  I have reported this to the Saxon list:
> http://saxon.markmail.org/thread/6pl67bho52t2ompb.
>
> Therefore, on the above branch, the following tests are the only tests
> to fail, still:
>
> - testXquery006
> - testXslt2003
> - testXslt006
> - testXslt2002
>
> Regards,
>
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
>
>
> On 29 October 2016 at 19:59, Florent Georges wrote:
>> Hi,
>>
>> I have a project depending on both Saxon and Calabash.  I have upgraded it to
>> Saxon 9.7, but I am blocked by the lack of support of Calabash for Saxon 9.7.
>> So I created a new branch and adapted Calabash codebase to Saxon 9.7.  You can
>> find the changes at https://github.com/fgeorges/xmlcalabash1/commits/saxon97.
>>
>> The test suite reports: "717 tests completed, 9 failed"  Out of these 9, 5 are
>> because I use HE and they require EE (because it is about Schematron validation,
>> I doubt upgrading Saxon would break them, but I can't test them):
>>
>> - Optional.testValidsch001
>> - Optional.testValidsch002
>> - Optional.testValidsch003
>> - Optional.testValidsch004
>> - Optional.testValidsch005
>>
>> 2 tests are failing because the default collection is not set:
>>
>> - Optional.testXquery006
>> - Optional.testXslt2003
>>
>> And finally, 2 tests are failing because the base URI is not set correctly on a
>> secondary document created by xsl:result-document in a pipeline:
>>
>> - Required.testXslt006
>> - Optional.testXslt2002
>>
>> This last error is due to Saxon setting the wrong system ID in that case.  Given
>> what's in ElementCreator.java at line 350, it looks like it sets the document
>> node system ID to the one of its root element (inheriting it from the stylesheet
>> source in the pipeline file), instead of using the one from the `href` attribute
>> on xsl:result-document.  Not sure this is because of Saxon or of a
>> change in 9.7.
>> The following is the stack trace from the point where the wrong system
>> ID is set:
>>
>> at net.sf.saxon.event.ComplexContentOutputter.setSystemId(ComplexContentOutputter.java:134)
>> at net.sf.saxon.event.ProxyReceiver.setSystemId(ProxyReceiver.java:40)
>> at net.sf.saxon.event.ComplexContentOutputter.setSystemId(ComplexContentOutputter.java:134)
>> at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:350)
>> at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:311)
>> at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:149)
>> at net.sf.saxon.expr.instruct.ResultDocument.processInstruction(ResultDocument.java:470)
>> at net.sf.saxon.Configuration.processResultDocument(Configuration.java:2132)
>> at net.sf.saxon.expr.instruct.ResultDocument.process(ResultDocument.java:382)
>>
>> So it is definitely not 100% complete, but except for these 2 corner cases (WRT
>> the default collection and secondary outputs in XSLT), it seems to be working
>> fine.  It is maybe time to add beta support for 9.7, released 1 year ago and to
>> which most projects relying on Saxon seem to have been moved to, even if only
>> 99% of the test suite pass.  Having this support in beta status for one or a few
>> versions of Calabash would help gather feedback as well.
>>
>> Not sure whether it is possible to create a pull request for a new branch, but
>> happy to investigate if you want me to.
>>
>> Regards,
>>
>> --
>> Florent Georges
>> http://fgeorges.org/
>> http://h2oconsulting.be/

Received on Sunday, 6 November 2016 18:13:15 UTC