- From: Adam Retter <adam@exist-db.org>
- Date: Thu, 14 Mar 2013 11:39:49 +0000
- To: Michael Kay <mike@saxonica.com>
- Cc: public-expath@w3.org
>> A second stream of consciousness: >> >> I feel very uneasy about representing octets using integers. So I ask >> myself why? Is it history - i.e. eXist and Zorba (maybe others) >> represent octets as octal strings and allow for the conversion of >> octal to/from decimal with functions. > > Odd, I haven't seen octal used in anger for about 25 years, I thought it was > completely obsolete. But then I guess I've managed to avoid writing in C. > Every since the industry standardized on an 8-bit byte, hexadecimal has > seemed much more natural. So perhaps I should elaborate on my use case for Octal numbers. In eXist-db we implement as a minimum a Unix style permission model, this is convenient for many of our users as they already understand the Unix permission model. So each file in eXist-db has a 'mode' which people are used to expressing as an octal number. e.g. sm:chmod(xs:anyURI("/db/myfile.xml"), "0770") Would change the mode of 'myfile.xml' to 0770 (i.e. rwxrwx---). So yes we have users that know and are used to working with Octal numbers, in the past we used to expect people to supply an xs:integer equivalent, but that was really a pain in the ass, as its hard for users to know that 0770 is equal to 504. Its much easier to think of these mode values in octal as read (4) write(2) and execute (1) can easily be composed and understood by humans whereas an integer mask cannot. >> >> An octet is implicitly in Base 8 > > Eh? if it's anything, surely it's implicitly in base 2? Maybe we are talking at cross purposes? I am talking about octal numbers, i.e. the number system base 8 where a single value can be in the range of 0 - 7. >> , 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 - >> >> If I understand correctly - >> >> bin:binary-to-octets(xs:hexBinary("FFFF")) would give me (255, 255) > > Seems natural to me. > >> >> Rather if you want to go to base10 then >> bin:binary-to-radix(xs:hexBinary("FFFF"), 10) could give me 65535. > > But there's nothing intrinsically decimal about the value 65535, other than > the way it's being printed on the page. > > bin:binary-to-radix(xs:hexBinary("FFFF"), 17) would give you exactly the > same integer - it only becomes base 17 when you convert the integer to a > string to display it. > >> >> >> All of the bitwise operators seem to operate on xs:hexBinary > > Yes, I think it's a separate discussion whether bitwise operators on > integers would be more useful. I think the main problem is that we don't > have hex literals, so we can't say $x & xFF00, instead we have to say either > > (1) if we use hexBinary: bin:and($x, xs:hexBinary("FF00")) > (2) if we use base64Binary: bin:and ($x, xs:base64Binary("/wA=")) > (3) if we use integer: bin:and($x, 65280) > > None of these is nice, but the first seems to me the most readable. If we go > with (and/or/not) working on integers, then perhaps we should also have > functions > > bin:hex("FF00") => 65280 > > bin:octal("177400") => 65280 (since you're telling me that there are indeed > people who still use octal...) > > Michael Kay > Saxonica > -- Adam Retter eXist Developer { United Kingdom } adam@exist-db.org irc://irc.freenode.net/existdb
Received on Thursday, 14 March 2013 11:40:20 UTC