This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Efficient Extensible Interchange Working Group
Other specs in this tool
Quick access to LC-2705
There are 11 comments (sorted by their types, and the section they are about).
Subject: Event code length for xsi:type attribute event
Section: 2.1 Grammar Learning Disabling Mechanism
Paragraph: "The xsi:type attribute event MUST always be represented by the AT(*) production whose
event code length is 2."
I am sure there is a good reason to require this but I cannot deduct it. Maybe a hint in the spec
will make the job of the implementers easier. My guess is that this is connected to the separation
of the "original" xsi:type attributes and the xsi:type attributes added because of the Profile.
(Note also: "For a given element E, the disabling of grammar learning E ..."
should be "For a given element E, the disabling of grammar learning for E ...";
"..., the following rule happens:" it is better "..., the following rules apply:")
When reading up on the EXI specification section "7.3.3 Partitions
Optimized for Frequent use of String Literals" last two paragraphs
regarding the processing of value content items, I have one more issue
to rise connected to the EXI Profile:
In section "3. Local Value Capping" the parameter localValuePartitions
is used to turn on or off the use of local value partitions. Note
however that this same effect can be achieved by the use of the EXI
parameter valuePartitionCapacity - it is not only used for the global
Setting valuePartitionCapacity to 0 effectively turns off both local and
global value string tables.
So the localValuePartitions parameter of the EXI profile has effect only
when valuePartitionCapacity is greater than 0.
However, the use of global value tables (valuePartitionCapacity > 0)
while turning off only the local value tables (localValuePartitions = 0)
is something that is highly unlikely to be useful in any scenario.
So why having yet another parameter for something that is already
available as option in the EXI specification?
Section: All spec
The conformance with the Profile does not guarantee in any way a bounded memory for processing
(for example not setting valuePartitionCapacity to 0 is enough to make a Profile complying
implementation consuming huge amount of memory). Moreover a non-conforming to the Profile
implementation can still use the Limiting the number of build-in grammars mechanism without
declaring that in the EXI header.
Without being an expert in the field my personal experience is that the EXI spec and even more the
EXI Profile spec are very much requiring the users to be aware of some implementation issues in
order to use the format in an optimal way.
For example, I was involved to some small extend in the Smart Energy Profile 2.0 standard/draft
that considers using EXI. Main goal is compactness but also lean processing. The knowledge on what
is the optimal way to set all the parameters (schemaId, preserve, selfContained, valueMaxLength,
valuePartitionCapacity and now the Profile parameters) is simply not there.
The great flexibility provided by having so many things to tune is working against the wide spread
adoption. The users should not be burdened by knowing what all these parameters mean especially
the Profile ones that are purely connected to the implementation.
Again, without claiming to be an expert and have a wide range of use cases in mind, I think a more
restrictive Profile that actually provides some guarantees and not so much freedom of setting
implementation parameters will be much more useful. In any case the actual use of the EXI Profile
will require some "Application-specific Profile" that defines the fixed values for all these
parameters. So why not preset all these parameters and provide some guarantees with a good memory
usage vs compression trade-off? I know one size does not fit all, but then why defining an EXI
Profile in the first place?
In any case, if every single application sets these parameters in a different way then the
implementations won't be able to interoperate due to some memory issues or size constrains. What I
see as a need is a Profile that provides some guarantees for resource constrained devices. For
example, a conforming implementations should use only:
- maximumNumberOfBuiltInElementGrammars = 0
- valuePartitionCapacity = 0
- maximumNumberOfBuiltInProductions = 0
- localValuePartitions = 0
- selfContained = false
- preserve = all false
- fragment = false
- either strict schema mode OR "schemaId" set to the empty value schema-less mode
Note that by fixing the values of these parameters will not only make the RAM consumption
predictive but also lower the programming memory which is also an issue in some cases. The
implementations of the Profile will be much simpler as a codebase as compared to implementing the
generic version of the Profiles as it is now. In fact, the Profile as it is now will just extend
the code and make it more complex which I believe is the opposite of what is needed for embedded
Subject: Evaluations of EXI in application areas with memory restrictions
Section: 1. Introduction
Paragraph: "Certain evaluations of EXI in the context of such areas..."
It is good to have access to these evaluations. From my own perspective and use cases this profile
will not bring much benefits. I am working with very small messages over low-bandwidth wireless
links (up to 250 kb/s). Of course, memory is an issue but the compression is even more important.
It would be good to have some statistics on what are the trade-offs (memory usage vs compression)
by using the Profile in different use-cases (size and structure of the messages).
Subject: Limiting the number of build-in grammars and Limiting the evolutions of build-in grammars
Section: 2. Grammar Capping
Paragraph: Whole section
In the grammar capping section it is given a single mechanism to limit the number of build-in
grammars by using the xsi:type attribute (possibly with xsd:anyType). There is no mentioning of
the second very distinct mechanism described later on: limiting the evolutions of build-in
grammars by restricting the number of dynamic productions inserted. Mixing up between these two
mechanisms in the spec is the main source of confusion for me.
The other problem for us is to have option grammar parser. I have a 1kB grammar of full option grammar (without capability to parse user-defined metadata) and even want to reduce it. But, these option values useful for embedded devices are placed in 'lesscommon' or user defined metadata (otherwise, we can omit 'lesscommon' grammar -- more than half of the option grammar). In SEP2, as you know, we have decided to have static no-choice options :) and SEP2 nodes can skip parsing the option document (something like bitcmp(expected, given) works), and I would do the same way in other embedded applications.
Subject: Limiting the evolutions of build-in grammars
Section: 2.1 Grammar Learning Disabling Mechanism
Paragraph: "If grammar learning is disabled in the case of a production insertion in a given
grammar, named G, the following rule happens ..."
This is the first time the second mechanism (Limiting the evolutions of build-in grammars) is
mentioned in the spec. It is almost impossible to make the connection with the rest of the spec
without reading it few/several times. In my opinion this mechanism should be clearly described and
differentiated with the first one (using xsi:type).
A proper way of doing this is by mentioning it in the 2. Grammar Capping sections and then
describing it as a separate subsection. Giving it a proper name would also help a lot as "grammar
learning is disabled in the case of a production insertion" is definitely not a good one.
Subject: The Profile parameters
Section: 4. Parameters representation
Paragraph: "In such a case, the actual profile parameters (or fine-grained capping strategies)
should be defined by an out-of-bound mechanism."
The maximumNumberOfBuiltInElementGrammars and localValuePartitions parameters should not be
mandatory to be set/communicated-out-of-bound in my opinion. For the number of build in grammar
the encoder knows the number of the grammars so no need to be included in the header. On the
decoder side if the implementation is "smart" it won't create a new build-in element grammar
before examining the next event. If it is a xsi:type="SOME_EXISTING_TYPE", there is no need to
create a new build-in element grammar.
For the localValuePartitions again - no issues for the encoder if the parameter is not included in
the header. The decoder on the other hand can create local value tables only if it has enough
memory to do so. If it cannot support local value tables, it will only expect string values
represented literally in the stream. Receiving a string as a compact identifier will produce error
during decoding in any way if the decoder does not have enough memory.
Subject: Confusing description
Section: 2.2 Grammar Learning Disabling Parameters
Paragraph: "Grammar learning is disabled...
Grammar learning is disabled in the case of a production ..."
There should really be a better name for "Grammar learning is disabled in the case of a
production ..." A suggestion: "Disabling the evolution of build-in grammars"?
Section: C Prefix Workarounds (Non-Normative)
All the paragraph could be summarize by saying that the application should use only ONE prefix per
namespace. Then the two requirements are fulfilled.
Subject: Striping of Profile xsi:type attributes
Section: E.2 Grammar Restriction Decoder Considerations
Paragraph: "An EXI profile decoder SHOULD strip any xsi:type attribute with the xsd:anyType value
from the infoset that corresponds to the grammar learning disabling mechanism."
It is strange to have "SHOULD" in a (Non-Normative) section. In any case a non-Profile EXI decoder
will include the Profile xsi:type attributes.
Add a comment.