RE: Constraint on string tables

Hello Stanley,

Thanks for your interest in EXI!

Sorry that it took me so long; but let me try to give you an answer,
after discussion with the EXI WG:

> Section 7.3 specifies that"
> 
> "The life cycle of a string table spans the processing of a single EXI
> stream. String tables are not represented in an EXI stream or 
> exchanged
> between EXI processors. A string table cannot be reused 
> across multiple
> EXI streams; therefore, EXI processors MUST use a string table that is
> equivalent to the one that would have been newly created and 
> pre-populated
> with initial values for processing each EXI stream."
> 
> Why is this constraint included?  It appears to imply that the string
> table must be rebuilt for each message in a communications 
> context.  If a
> number of strings are known to occur repeatedly in a particular
> communications context, why not allow the string table to be 
> optionally
> pre-populated for that context, just as schemas are permitted to be
> optionally specified?

First, your understanding of the spec's intention is correct. :-)

Second, why was this done? EXI works more efficiently by having more
knowledge about the data at hand. In the current design, all such
a-priori knowledge is encoded in XML Schema (other than the generic
knowledge of XML / XML Namespaces itself). Adding additonal sources of
such knowledge has a number of far reaching consequences on design
complexity and especially for deployment. For example, content
negotiation becomes significantly more complex if there are multiple
items that need to be negotiated before an EXI document could be
understood. The current feeling of the group is that the added
complexity would be rather detrimental.

Third, what other options are there? There's two alternatives I'd like
you to consider:

If the known repeated strings occur in particular contexts, you might
consider writing an schema for encoding purposes that would use
enumerations in those particular places. Note that due to full support
for schema deviations, you can still encode arbitrary XML documents.
It's just that by supplying an appropriatly modified schema with
enumerations, you can inform the EXI processor about exactly which
strings are expected in which places.

In case you are more worried about a sequence of messages and wish to
preserve state across transmissions, you might consider encoding the
entire message sequence as a single EXI fragment. That is, from the EXI
point of view the entire exchange is a single EXI document. The root of
each individual message would then essentially add one node to the
fragment. Once each such message/fragment node is encoded, it could be
incrementally transmitted in order to achieve the actual message
exchange. That would allow to preserve all encoding state throughout the
entire session, and fully within the framework of the current EXI draft.


Stan, I hope this answers your question. If not, please let us know what
you think!


Sincerely,
Daniel Vogelheim

Received on Tuesday, 7 August 2007 11:26:28 UTC