- From: Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com>
- Date: Mon, 11 Jan 2016 09:52:02 +0000
- To: Alessandro Triglia <sandro@oss.com>, "public-exi@w3.org" <public-exi@w3.org>
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