- From: Cokus, Michael S. <msc@mitre.org>
- Date: Mon, 8 Jun 2009 11:24:40 -0400
- To: "sklein@cpcug.org" <sklein@cpcug.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>
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)
Received on Monday, 8 June 2009 15:25:15 UTC