EXPath Binary - accessing sections outside the binary data sequence

In finalising the specification a number of issues have arisen about the 
behaviour of some functions when offsets that point /outside/ the range 
of the binary data are used. Mainly these concern bin:part() and 
bin:insert-before()though a few others might suffer similar issues.

Originally bin:insert-before($in,$offset,$extra)raised an error when 
$offset was negative or beyond the data of $in. However, comparison with 
fn:insert-before() suggests a little more leniency - when $offset lies 
outside bounds, the extra content could be added at the appropriate end. 
This can be carried out easily.

My issues really arise with bin:part($in,$offset,$size?). Again, 
currently the spec. has errors raised when $offset or $offset+$size lie 
outside bounds. There is some lobbying for a relaxation, most probably 
in two circumstances: i) where $size is 0, i.e. octets aren't actually 
being read, or ii) when $offset just touches the end of the data. There 
could be more extreme cases where 'zeros' are returned. Part of the 
argument comes from analogies with void expressions and operators  (e.g. 
12 + @price) where you want silent behaviour with predictable defaults. 
This I can understand.

However I'm having some difficultly deciding where the line should be 
drawn. For example if $in is 3 octets long, should we raise an error on 
bin:part($in,3,0) or return xs:base64Binary("")or even empty-sequence()? 
What happens when it's bin:part($in,4,0), or much more worryingly 
bin:part($in,4,1) or bin:part($in,-1,1) ? - surely in the latter cases 
we MUST raise errors, otherwise any use of bin:part() in 
non-void-expression situations needs pre-checking code, as no errors 
will ever be raised. Perhaps it comes down to the more probable use 
cases we expect.

I'm somewhat confused and find changing the spec. and test suite(and 
implementation) around repeatedly in these areas to be rather 
frustrating. There are implications on the raise-error/default-void 
behaviours that we need to get some agreement on.

John


-- 
*John Lumley* MA PhD CEng FIEE
john@saxonica.com <mailto:john@saxonica.com>
on behalf of Saxonica Ltd