- From: Christian Grün <christian.gruen@gmail.com>
- Date: Wed, 13 Mar 2013 23:11:24 +0100
- 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
Christian
[1] http://docs.basex.org/wiki/Conversion_Module#convert:binary-to-bytes
Received on Wednesday, 13 March 2013 22:12:27 UTC