W3C home > Mailing lists > Public > public-expath@w3.org > March 2013

Re: Draft of Binary module

From: Christian Grün <christian.gruen@gmail.com>
Date: Wed, 13 Mar 2013 23:11:24 +0100
Message-ID: <CAP94bnOewELtuuTWD2j=TYwDjqaH2TJaUEHF0rQHuONSz6vsPg@mail.gmail.com>
To: Adam Retter <adam@exist-db.org>
Cc: Florent Georges <fgeorges@fgeorges.org>, Michael Kay <mike@saxonica.com>, EXPath <public-expath@w3.org>
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


[1] http://docs.basex.org/wiki/Conversion_Module#convert:binary-to-bytes
Received on Wednesday, 13 March 2013 22:12:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:36 UTC