Re: Draft of Binary module

Hi Adam,

>>> An octet is implicitly in Base 8, so why would I then want to
>>> manipulate it as thought it were Base 10 (but without
>>> converting it to Base 10). This just doesnt make sense to me -

In our analog BaseX function [1], we return items of type xs:byte
instead of xs:integer. xs:unsignedByte could have been a more
convenient alternative. I agree that a byte sequence takes much less
space than a full integer sequence. On the other hand, most XPath
functions work with integers, which is why you will usually end up
with a 32bit representation of your value anyway. From the
implementor’s perspective, I believe it should usually be possible to
find memory-saving optimizations for both variants; but it would be
interesting to hear more about other implementations.

> bin:binary-to-octets(xs:hexBinary("FF")) + 1 would give me (256)

The same will actually happen when you are working with bytes, as your
byte value will implicitly be cast to an integer:

  xs:unsignedByte(255) + 1 → 256

You could limit the result to the lowest eight bits, as it is done in
other languages:

– XPath: binary:and( xs:unsignedByte(255) + 1, 255) → 0
– Java/C style: ((byte) 255 + 1) & 255



Received on Wednesday, 13 March 2013 22:12:27 UTC