- From: Alessandro Triglia <sandro@oss.com>
- Date: Tue, 22 Dec 2015 21:04:57 -0500
- To: <public-exi@w3.org>, "'John Schneider'" <john.schneider@agiledelta.com>
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