- 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