Re: Call for opinions on how to represent empty elements in Canonical EXI

Note: Approach B also generates the same sequence of events for all data types and does not require schema knowledge to work. This latter characteristic reduces implementation complexity and yields faster processing speeds.

> On Dec 21, 2015, at 1:31 PM, Takuki Kamiya <tkamiya@us.fujitsu.com> wrote:
> 
> Hi,
> 
> There are two approaches proposed on how to define rules regarding 
> the encoding of empty elements in schema-informed context.
> 
> Please provide any opinions as to which of those approaches you 
> consider more appropriate to have as part of Canonical EXI.
> 
> The behavior of each approach is described below.
> 
> Approach A: This approach always first tries to encode empty elements 
> (i.e. SE followed by EE, optionally AT, etc. in between) as a sequence of 
> SE CH EE (optionally AT etc. between SE and CH) where CH is used for 
> representing empty string, for elements defined to have simple-content,
> as long as doing so is possible (i.e. unless the codec in effect does *not* 
> permit to encode empty string "").
> 
> Approach B: This approach encodes empty elements (i.e. SE followed by EE, 
> optionally AT, etc. in between) as a sequence of SE EE (optionally AT etc. 
> in between). As an exception, for elements defined to have simple-content,
> it is allowed to insert CH that represents empty string "" between SE and EE
> only when doing so is necessary for representing an empty element there.
> 
> Note the approach B provides better efficiency, while approach B leads to 
> generate the same sequence of events whether strict or non-strict mode.
> 
> Thank you,
> 
> Takuki Kamiya
> Fujitsu Laboratories of America
> 
> 
> 
> 

AgileDelta, Inc.
john.schneider@agiledelta.com
http://www.agiledelta.com
w: 425-644-7122
m: 425-503-3403
f: 425-644-7126

Received on Monday, 21 December 2015 22:59:31 UTC