- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Sat, 3 Aug 2013 15:42:57 +0100
- To: Christian Grün <christian.gruen@gmail.com>
- Cc: Michael Kay <mike@saxonica.com>, EXPath <public-expath@w3.org>, John Lumley <john@saxonica.com>
On 2 August 2013 23:53, Christian Grün wrote: Hi Christian, Thanks for your comments! Below a few notes about them, just my 2 cents... > – the name of the bin:subsequence() function may be irritating > as it returns no sequence, but zero or one xs:base64Binary > item. Possible alternative could be: bin:sub(), bin:range() or > bin:split(). I agree. What about bin:slice()? > – personally, I would get rid of BINA0005 ($search is empty > binary data) [...] > – it could also be discussed if negative and out-of-bounds > integer should be rejected [...] > On the oher hand, I can see that more rigid error messages may > lead to better code, and it might be that the tolerant behavior > of XPath functions would be handled differently today (?). I am personally in favour of more strict error checking, so I would keep BINA0005, and reject invalid boundaries for the same reason. > – as signed numbers are the default in the XQuery data model, > bin:unpack-signed-integer() could possibly renamed to > bin:unpack-integer() +1 > – have you thought about letting the bit functions operate on > octets (xs:integer*) instead of base64? We already discussed this. I did not look into the archive, but as far as I can remember, I think the outcome was that you can't have a sequence of 2 binaries in that case, because we can't have sequences of sequences (e.g. a function could not return 2 binary items). Using xs:base64Binary (for instance) does not have this problem. Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
Received on Saturday, 3 August 2013 14:43:45 UTC