Re: EXPath binary - subsequence()

The spec for substring dates from XPath 1.0, where

(a) double was the only data type

(b) there was a strong desire to avoid raising dynamic errors (based on the browser use case, where the aim is to never show an error message to the end user).

In XPath 2.0 the spec for substring was unchanged for compatibility, although in general the design principles for new functions were such that if starting from scratch, the arguments would certainly have been integers, and negative positions would probably have been rejected. I remember there was talk of changing it, but there are coding patterns in XPath 1.0 that exploit the ability to use arguments like positive and negative infinity, so it was retained.

subsequence() was introduced in XPath 2.0 and the spec was made consistent with substring() purely for the sake of consistency, but in my view this was probably misguided.

I think we're right in the binary module to ignore this legacy and design the function as we think it should be, not to repeat the mistakes of the past.

The only real benefit of using doubles is that you can pass untypedAtomic, but the start and length arguments are unlikely to be extracted by atomizing a node.

The case for not raising errors has pretty well disappeared now that we have try/catch, and XPath 2.0 had already changed the principles so that for most operations bad arguments led to a dynamic error rather than fallback behaviour.

Mike


On 12 Jul 2013, at 08:53, John Lumley wrote:

> Working though the first draft, I noticed that while fn:subsequence() and fn:substring() use xs:double for offset and length (with appropriate rounding), bin:subsequence() proposes using xs:integer. Also the former treat negative offset as working from the start, and 'long' results are truncated to 'data end' rather than both situations raising errors, as proposed for bin:subsequence(). (I am not implying fractional values to pull in part octets!)
> 
> Are there any specific use cases, or other reasons, to use a different offset/length signature, or error regime, than is used in fn:xxx() ?
> 
> John
> -- 
> John Lumley MA PhD CEng FIEE
> john@saxonica.com 
> on behalf of Saxonica Ltd