Edit comment LC-3077 for Efficient Extensible Interchange Working Group

Quick access to LC-3041 LC-3042 LC-3043 LC-3044 LC-3045 LC-3065 LC-3066 LC-3067 LC-3068 LC-3069 LC-3070 LC-3071 LC-3072 LC-3073 LC-3074 LC-3075 LC-3076 LC-3077 LC-3078

Comment LC-3077

Comment Shortname:

Commenter: John Schneider <john.schneider@agiledelta.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a whole1. Introduction Canonical EXI Abstract 1.1 Notational Conventions and Terminology 1.2 Need of Canonical EXI 1.3 Applications 1.4 Limitations 2. Canonical EXI Stream 3. Canonical EXI Header 4. Canonical EXI Body 4.1 EXI Alignment Options and Streams 4.2 EXI Event Selection 4.2.1 Prune productions according to specific conventions 4.2.2 Prune productions for non applicable events with content values 4.2.3 Use the event with the most accurate event 4.3 EXI Stream Order 4.4 EXI Datatypes 4.4.1 Unsigned Integer 4.4.2 Enumeration 4.4.3 Decimal 4.4.4 Float 4.4.5 Date-Time 4.4.6 String and String Table 4.4.7 Restricted Character Sets 4.4.8 Datatype Representation Map A Design Decisions A.1 Relationship to XML Security A.2 No Unicode Normalization B Canonical EXI Examples B.1 EXI Event Selection Example B-1. Example productions with event codes B.2 EXI Stream Order Example B-2. Attribute and Namespace Declaration Sorting Figure C-1. Canonical EXI used in Signature B.3 EXI Floats Example B-3. Example algorithm for converting float values t... Example B-4. Canonicalized EXI Float values C Canonical EXI Applications C.1 Signature Processing Steps C.2 Exchange EXI Options (Best Practices "Work in Progress") C.2.1 Option 1 - XML Signature element C.2.2 Option 2 - Uri scheme fragment identifier C.2.3 Option 3 - EXI options within EXI stream D References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody Bournez, Carine Brutzman, Don Cokus, Michael Fernández, Javier D. Heuer, Joerg Käbisch, Sebastian Kamiya, Takuki Kuntschke, Richard Matsukura, Ryuichi McGregor, Don Peintner, Daniel Quin, Liam Shah, Grishma ZERGAOUI, Mohamed

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

I’ve been following the discussion regarding Canonical EXI’s treatment of
empty elements and would like to offer a suggestion to simplify the wording
and improve the efficiency of the proposed solution.

Here is what I would propose:

“When strict is false or the current element grammar contains a production
of the form LeftHandSide : EE with event code of length 1, EXI can represent
the content of an empty element explicitly as an empty CH event or implicitly
as a SE event immediately followed by an EE event. In these circumstances,
Canonical EXI MUST represent an empty element by a SE event followed by an
EE event.”

I think this description states the issue and the alternate solution simply
and clearly. The alternate solution improves compactness by prescribing
the most efficient representation of an empty character event when it is
available (i.e., by omitting the CH event). It improves processing efficiency
by requiring only 1-2 checks (strict & available EE) and does not require
knowledge or checking against DTR types. These checks occur in a relatively
hot code path, so minimizing overhead is important for efficiency. Because
the alternate approach does not depend on DTR knowledge, it also avoids the
need to describe how to handle user defined DTRs that can also encode empty
strings (which the current proposal does not address).

Related issues: (space separated ids)

WG Notes: The resolution was based on the commenter's original opinion.

Resolution: 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. --------------------------------------------------------------------- After considering several opinions that were discussed here on this issue [1], the group agreed to take approach B. The editor's draft [2] will soon reflect this decision. [1] https://www.w3.org/2005/06/tracker/exi/issues/112 [2] https://www.w3.org/XML/EXI/docs/canonical/canonical-exi.html#emptyElementContent

(Please make sure the resolution is adapted for public consumption)