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

Re: Final draft of Proposed Binary Module

From: Michael Sokolov <sokolov@falutin.net>
Date: Thu, 14 Nov 2013 11:17:19 -0500
Message-id: <5284F78F.6050101@falutin.net>
To: Jirka Kosek <jirka@kosek.cz>
Cc: John Lumley <john@saxonica.com>, EXPath ML <public-expath@w3.org>
On 11/14/2013 10:46 AM, Jirka Kosek wrote:
> On 14.11.2013 11:35, Michael Sokolov wrote:
>> I'm also curious why packing and unpacking functions aren't specified as
>> taking/returning sequences of numbers.
> Because xs:base64Binary is the primary type used for representing binary
> values.
I'm sorry, I don't think I was clear.  What I meant was

|bin:pack-integer|(|$in|| as ||xs:integer|, |$size|| as 
||xs:integer|)| as ||xs:base64Binary

could be

|bin:pack-integer|(|$in|| as ||xs:integer|*, |$size|| as 
||xs:integer|)| as ||xs:base64Binary|

which would pack a sequence of integers, one after the other, into a binary

I guess without that we would do something like

bin:join (for $i in $ints return bin:pack-integer($i, 4))

which is fine.  I was just wondering if we were making it harder to 
optimize, and also wondering if there might be some XQuery 3.0 function 
mapping way of doing this that I haven't learned yet :)
>>   Is the idea that any conceivable
>> optimizations can be achieved just as easily by mapping the functions or
>> using them with function operators?
> I'm note sure if I understand to you question. But xs:base64Binary is
> just abstraction from the point of view of function signatures.
> Reasonable implementations will store values of this type as arrays of
> bytes without any additional overheads.
> 			Jirka
Received on Thursday, 14 November 2013 16:18:37 UTC

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