- From: Michael Kay <mike@saxonica.com>
- Date: Wed, 7 Jun 2017 16:34:43 +0100
- To: Adam Retter <adam.retter@googlemail.com>
- Cc: EXPath ML <public-expath@w3.org>
> On 7 Jun 2017, at 16:09, Adam Retter <adam.retter@googlemail.com> wrote: > > Okay so if I understand, you are saying, don't do the check up front, > do the check afterwards and report if less than size was read? > > I can see the argument that there is value there for the user, > however, it is very hard to implement for us because of the streaming > nature. > > If we consider bin:part#3 it takes a xs:base64Binary and returns a > xs:base64Binary. Internally for us it takes a stream and returns a > stream, also we don't actually do anything with the stream until it is > actually realised, this makes tracking the error very hard, in the > face of nested functions on xs:base64Binary. I will give some thought > to how we can catch the underlying IOException and relate it to the > correct expression; it's tricky because effectively the `stream` > escapes the scope of the enclosing expression. It doesn't seem very difficult to me to have an implementation of stream that fails at end-of-data() time if the length is less than N. But I think my approach here would be different. I would support the bin:part#3 function as specified, albeit inefficiently, and offer a different function perhaps bin:read-up-to($in, $start, $len) which reads from $start to the end of $in or to $len whichever comes first. Michael Kay
Received on Wednesday, 7 June 2017 15:35:13 UTC