- From: Christian Grün <christian.gruen@gmail.com>
- Date: Wed, 27 Nov 2013 13:52:18 +0100
- To: John Lumley <john@saxonica.com>
- Cc: EXPath ML <public-expath@w3.org>
> 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. My knowledge here is that the lenient handling of arguments goes back to XPath 1.0, whereas more recent functions tend to be stricter – and I think we should be strict in the Binary Module, too. Otherwise, we would need to relax many other functions in the module as well. > 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()? An empty sequence could to lead to all kinds of unexpected behavior, so returning an empty Base64 is my clear favorite. > 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. Similar to bin:insert-before, raising errors is the only solution that I would regard as consistent. Any other opinion on this? Christian
Received on Wednesday, 27 November 2013 12:53:05 UTC