W3C home > Mailing lists > Public > public-expath@w3.org > June 2017

Re: Bin Module does not work well with Streams

From: Michael Kay <mike@saxonica.com>
Date: Wed, 7 Jun 2017 16:34:43 +0100
Cc: EXPath ML <public-expath@w3.org>
Message-Id: <64423735-FD3D-419B-9ABA-8629777275B8@saxonica.com>
To: Adam Retter <adam.retter@googlemail.com>

> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 June 2017 15:35:13 UTC