W3C home > Mailing lists > Public > www-tag@w3.org > June 2009

Re: Numeric Representation (was RE: TAG review of EXI Best Practices)

From: Stanley A. Klein <sklein@cpcug.org>
Date: Mon, 8 Jun 2009 12:13:59 -0400 (EDT)
Message-ID: <42655.71.163.213.188.1244477639.squirrel@www.cpcug.org>
To: "Cokus, Michael S." <msc@mitre.org>
Cc: "Taki Kamiya" <tkamiya@us.fujitsu.com>, "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "public-exi@w3.org" <public-exi@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
Mike -

Part of my question was whether there might be built-in datatype
representations I hadn't noticed.  I looked at the links you provided, and
there are.  That answers my question.

Your answer clarifies how the compactness in comparison to ASN.1 PER can
be reached for sensor data and telemetry.

Thanks.


Stan Klein



On Mon, June 8, 2009 11:24 am, Cokus, Michael S. wrote:
> Stan,
>
> I apologize for the delay in responding.  The working group has discussed
> your question, but we are not sure we understand.  EXI does not represent
> integers and floats as strings.  EXI has built-in datatype representations
> for numeric data that are a bit more compact.  We may be missing your
> point; could you please provide some clarification?
>
> Thanks much,
>
> --mike
>
> Mike Cokus (for the EXI WG)
>
>
> http://www.w3.org/TR/2008/WD-exi-20080919/#encodingInteger
> http://www.w3.org/TR/2008/WD-exi-20080919/#encodingFloat
>
> Mike Cokus
> The MITRE Corporation
> 757-896-8553; 757-826-8316 (fax)
> 903 Enterprise Parkway
> Hampton, VA 23666
>
>>I don't understand some of the document's conclusions regarding
>>compactness in comparison to ASN.1 PER.  Do the conclusions apply to
>>cases
>>where the data is naturally binary, such as 32 bit integer or real?  The
>>use case I have in mind is sensor data.  I didn't notice a feature in
>>EXI
>>that allowed 32 bit binary to be sent without converting it to
>>character,
>>as would occur in transmitting a value as XML.
>>
>>I think that can be done by using a user-defined datatype
>>representation,
>>but that is the only way I can identify.  If that is the case, there
>>probably needs to be a standard "user-defined" datatype representation
>>that escapes to four octets for representing 32 bit binary or 8 octets
>>for
>>64 bit binary, with definitions in each case for integer and real.
>>
>>Alternatively, if the compactness of naturally binary data using EXI is
>>as
>>good or better than ASN.1 PER +20%, how does that happen?
>>
>>
>>Stan Klein
>>
>>
>>
>>On Tue, April 21, 2009 4:33 pm, Taki Kamiya wrote:
>>> Dear Noah and TAG members,
>>>
>>> We would like to call the TAG's attention to the recent publication of
>>the
>>> second working draft of the EXI Evaluation working note [1].
>>>
>>> The primary change since the first draft is the addition of processing
>>> efficiency results which indicate the expected performance of
>>> EXI relative to XML and XML+GZIP for both encoding and decoding.
>>>
>>> We hope that the data addresses concerns that we have discussed
>>previously
>>> in joint sessions between the TAG and the EXI WG. We will be convening
>>> a face-to-face meeting during May 5-7th.  We would appreciate any
>>feedback
>>> the TAG can provide by that time.
>>>
>>> [1] http://www.w3.org/TR/2009/WD-exi-evaluation-20090407/
>>>
>>> Best regards,
>>>
>>> Mike Cokus and Taki Kamiya
>>> (EXI Working Group co-chairs)
>


-- 
Stanley A. Klein, D.Sc.
Managing Principal
Open Secure Energy Control Systems, LLC
8070 Georgia Avenue
Silver Spring, MD 20910
301-565-4025
Received on Monday, 8 June 2009 16:14:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:14 GMT