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

All,

First of all I wish you all a good start into the new year!

I recently updated the Editor's Draft of Canonical EXI to reflect the latest proposals w.r.t. to "Empty element content" [1] by stating the two approaches.
Personally I do see pros and cons for both and I think we ought to agree the next days which way to go.

> By the way, are you guys also considering the case of a user application actually
> sending a CH "" followed by an EE?  I would think in this > case the canonical EXI
> encoding should be the same as if the application had sent just an EE and no CH.
> This is because the underlying infoset in the two cases is the same.
>
> More broadly, I am also wondering what happens in the case of an application sending
> a series of CH events instead of a single larger one.  For example, for an element
> <e>Jonathan</e>, the application could send SE CH "" CH "John" CH "athan" CH "" CH "" EE.

This is a very important aspect and the latest draft [2] takes into account the issue which was pointed out.

Please let me know if you have further comments,

Thanks,

-- Daniel

[1] http://www.w3.org/XML/EXI/docs/canonical/canonical-exi.html#emptyElementContent
[2] http://www.w3.org/XML/EXI/docs/canonical/canonical-exi.html#excludeExtraneousEvents



> -----Original Message-----
> From: John Schneider [mailto:john.schneider@agiledelta.com]
> Sent: Monday, December 21, 2015 17:59
> To: Takuki Kamiya <tkamiya@us.fujitsu.com>
> Cc: public-exi@w3.org
> Subject: 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, 11 January 2016 09:52:34 UTC