Comments on EMMA WD

Hello,

Dave Raggett suggested back in August, at the time of the publication of
the 1st version of EMMA [0] that my input on the document would be
welcome, with a specific focus on the QA aspect of the document.
The following review is loosely based on the QA Framework Specification
Guidelines [1], although I haven't tried to make an extact match of the
checkpoints described in these guidelines - a 1st WD being probably a
bit early for such a formal analysis.

* Normative vs informative:
A few sections are marked as either normative or informative, but it
would be really helpful to make this qualification appear on each
section; it tremendously help scanning a document when reviewing it,
and  even more when trying to implement it (or build a test suite for
it, etc.)

* use of RFC 2119 keywords
Using MUST, SHOULD, MAY as defined in RFC 2119 also helps a lot to
identify the conformance requirements defined in the specification and
see what their level of requirement is.

* "classes of product"
The specification guidelines define the notion of "classes of product" 
[2], essentially the various types of implementations of the
specification. In the case of the EMMA language, there seem to be 3
basic classes of product: EMMA producers, EMMA consumers, and EMMA
"documents". Based on that, it would worthwile:
  - to use this terminoloy in the document for sake of consistency
between W3C Spec
  - to identify clearly in each of the conformance requirements set by
the specification which apply to which class of product.
For instance, the requirements set on emma:tokens could be re-organized
as:
  - the syntactic part which affects only EMMA documents (except syntax
errors that needs to be taken into account by the EMMA consumers)
  - the semantic part which affects both the EMMA producers and
consumers; e.g. an EMMA producer MUST identify the list of of input
tokens in an emma:tokens attribute set on an EMMA container element

* error mechanism
There are 2 mentions of possible errors met while processing EMMA, but
there is no error mechanism defined; I gather that it will be defined at
a later stage

* open issue on the syntax for EMMA
Between the 3 proposed solutions for the syntax of EMMA, my preferred
order would be 2, 1 and 3. (2) allows to re-use directly as is all the
efforts put in the RDF framework, and the processing overhead in this
domain doesn't appear to be obvious. If this processing overhead is
really so high, then (1) is preferable to (3) since it avoids to create
an unnecessary interoperability gap between applications.

* open issue on xml:lang
xml:lang as defined in the XML 1.0 Specification implies that "the
language used in the contents and attribute values" of the said element
is in the specific language; in the case of the current emma:lang, the
language information is to be applied on the input, not on all the
attributes and contents, so xml:lang doesn't seem appropriate. For
insance, one of the example of emma:lang would be wrong with xml:lang
<emma:interpretation emma:id="int3" xml:lang="fr"
   emma:process="http:/example.com/FrenchInterpreter.xml">
    <command> CANCEL </command>
    <emma:derived-from resource="#int1"/>
</emma:interpretation>
would imply that the <command> element has an xml:lang set to "fr",
while "CANCEL" is obviously not a French string.


Let me know if any of comments are unclear. In any case, I would be
interested to work with the Working Group on starting to apply some of
these ideas to its documents (EMMA and others).

Hope this helps,

Dom

0. http://www.w3.org/TR/2003/WD-emma-20030811/
1. http://www.w3.org/TR/qaframe-spec/
2. http://www.w3.org/TR/qaframe-spec/definitions#def-cop
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org