- From: Alessandro Triglia <sandro@oss.com>
- Date: Wed, 23 Dec 2015 13:05:28 -0500
- To: "'John Schneider'" <john.schneider@agiledelta.com>
- Cc: <public-exi@w3.org>
> -----Original Message----- > From: John Schneider [mailto:john.schneider@agiledelta.com] > Sent: Wednesday, December 23, 2015 12:25 > To: Alessandro Triglia <alessandrot60@live.com> > Cc: public-exi@w3.org > Subject: Re: Support for Canonical EXI interoperability test in TTFMS > > Alessandro, > > Its nice to hear from you! Yes, I’d be happy to clarify. > > The purpose of the statement is to precisely and unambiguously identify the > conditions under which EE is permitted and thus, identify when there are > two different ways to encode an empty element. When the first condition is > true (strict=false), there is always a production of the form LeftHandSide > : EE available in the current element grammar with an event code of length > 2 (IAW [1]). When strict is true, there is no production of this form with > event code of length 2 in the current element grammar and the only time EE > is available is when there is a production of the form LeftHandSide : EE in the > current element grammar with event code of length 1. So, the reason why > the EE event has to have an event code of length 1 is because this is the only > possibly allowed by the EXI grammars when strict is true. And yes, the > phrase “current element grammar” is used throughout the EXI spec to > identify the current non-terminal. > > That said, as I was thinking about your question it struck me that there is a > better way to express this condition. In particular, we could just say: > > “When the current element grammar contains a production of the > form LeftHandSide : EE, 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 would be an even simpler, more general and perhaps clearer way > to specify this rule in the spec. Yes, that is clearer. Thanks. Alessandro
Received on Wednesday, 23 December 2015 18:05:58 UTC