Re: Support for Canonical EXI interoperability test in TTFMS

John,

Could you please clarify the part of the sentence, "... or the current
element grammar contains a production of the form LeftHandSide : EE with
event code of length 1"?

The case of strict=false is clear to me.  I am looking at the case of
strict=true and I don't understand how the above condition addresses this
case.  Does the sentence contain an implicit condition that LeftHandSide be
the current nonterminal?  Also, could you explain why the EE event has to be
of length 1 in order to produce those effects? (Again, I am talking about
the strict mode; the non-strict mode is taken care of by the part of the
condition before the "or".)

I have read the recent public EXI emails on this subject and I agree with
everything you wrote on this topic, so I am not questioning the spirit of
your proposal, but the wording seems a little obscure to me.

Thanks,
Alessandro


From: John Schneider [mailto:john.schneider@agiledelta.com] 
Sent: Wednesday, December 16, 2015 14:34
To: Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com>
Cc: Takuki Kamiya <tkamiya@us.fujitsu.com>; public-exi@w3.org
Subject: Re: Support for Canonical EXI interoperability test in TTFMS

All,

I've thought about this more and talked to others and I'm still a bit
perplexed as to why we would take this approach. If I understand correctly,
every time we get an empty value, we are going to spend some extra time to
determine whether the associated DTR can represent the value less
efficiently as CH("") EE rather than just EE. And every time we determine
the DTR can represent the value less efficiently, we're going to do it. To
me, this does not seem like the best use of resources. 

The argument has been made that this approach is somehow more consistent
than always encoding the empty value the most efficient way possible.
However, this approach encodes empty values differently depending on their
data types and encodes the same document differently with schemas vs.
without schemas. So, as Taki has pointed out, it is inconsistent in
different - and to me more perplexing - ways.

The alternate proposal says always encode an empty value in the most
efficient way possible. Only encode it differently if the most efficient way
is not available. The original proposal says always encode the empty value
in the least efficient way possible. Only encode it differently if the least
efficient way is not available. And it requires implementations to spend
extra time to check if the DTR has the ability to encode the value less
efficiently. 

At the end of the day, its not clear to me why we would increase code
complexity and use more resources in order to detect and use a less
efficient encoding method. Once again, here is the alternate proposal:

"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."

Again, I hope this alternate proposal is helpful and serves to improve the
quality of the Canonical EXI specification.

Received on Wednesday, 23 December 2015 02:05:29 UTC