Saxon

As further background it is worth recording that we have upgraded to 9.6 (from 9.3) as it incorporates fixes for https://saxonica.plan.io/issues/1517 and an issue related to the handling of the totalDigits schema facet. These issues had directly impacted one of our clients.

We do not particularly need any major new features of 9.6 and our processor only requires XPath 2.0 compliance.

Thanks, that's interesting input.

I had been rather assuming that since the level of forwards compatibility between XPath 2.0, 3.0, and 3.1 is very high, we could start to think about dropping support for 2.0 once 3.1 becomes a Recommendation. Perhaps I need to think again.

The reason for string-join being the way it is is that we currently define the signatures of built-in functions in static data. We can define different subsets of the functions for each Configuration, but the current mechanism doesn't currently allow two different Configurations to have different signatures for the same function (or for the signature to depend on configuration settings). I would like to fix this but it's not trivial.

In addition the APIs for selecting a version of XPath or XQuery cause a lot of confusion, so I was hoping that by moving everything forward to 3.1 (eventually) we could make life a lot simpler for users.

Thanks for the quick response.

Unfortunately we are bound to XPath 2.0 - it is used by the XBRL International Fomula specifications (see http://specifications.xbrl.org/work-product-index-formula-formula-1.0.html) and they are very unlikely to move to XPath 3.0. If you aren't able to carry on supporting 2.0 (either in the form of future releases, or by porting bug fixes and performance improvements back to one or more earlier 2.0-compliant releases) then we would probably have to use a different processor.

In this case would it be possible to add an evaluation-time type check to the implementation of string-join, so that you could leave the signature the same?

We are looking again at 9.5 as it fixes the bugs we encountered in 9.3 but wouldn't have this one or bug 2736, and hopefully would not be as affected by bug 2723.

A well-known problem. W3C specs have generally been moving away from "fixed-version" references to other specs and towards "open-version" references, e.g. referencing "Unicode 4.0 or later". There have been too many of these problems, e.g. XSLT 1.0 referencing JDK 1.1.8 which is now pretty well unobtainable, even as a specification. Even where the specs appear to mandate a specific version, implementors have been taking a pragmatic approach in cases where a new version is both backwards compatible and easier to obtain.

There are a few details where edge-case conformance with an old spec becomes really difficult. An example is ensuring that if XSD 1.1 support is not enabled, string-to-double conversion rejects "+INF", which is the only value accepted by XSD 1.1 xs:double that is not also accepted by XSD 1.0. The contortions needed in the code to allow this edge case to be configurable are simply not worth the extra complexity, given that the only benefit is tick-box compliance. I think the string-join example falls into the same category.

I did look at special-casing the string-join issue with a run-time check, but that's not the way Saxon type checking works. At compile time, code is generated to do any necessary type checking or conversion based on the function signature. By the time the supplied value reaches the implementation of the function, it will already have been converted and we don't know what the original supplied value was.

On Saxon 9.9 (EE), the issue seems to have returned. The exact same usecase (XBRL conformance suite), expects XPTY0004 when using string-join() on non-string items, when having set the language version on XPathCompiler to 2.0. Looking at XPath20FunctionSet, it uses the same StringJoin.class as the XPath31FunctionSet, allowing any_atomc_type. Is the XPath 2.0 signature for string-join() dropped again, or am I missing something?

Kind regards,

Johan Walters