W3C home > Mailing lists > Public > www-multimodal@w3.org > August 2004

comments on WD-sysenv-20040728

From: olivier Thereaux <ot@w3.org>
Date: Mon, 30 Aug 2004 13:49:29 +0900
Message-Id: <FA465B3C-FA3F-11D8-8D9F-000393A80896@w3.org>
To: www-multimodal@w3.org

Dear MMI Working Group,

Here is a small review of the first public working Draft of "System and 
environment Framework" - 28 July 2004.

The document is a good first draft: it manages to lay out a lot of 
information in a rather clear and well described manner. Obviously it 
is not yet a mature specification, and it will probably have to undergo 
some reorganization before it is final. I hope that this half-editorial 
(comments marked as [Editorial]), half QA-focused (comments marked as 
[Conformance]) review will help you in this task.


1* [Editorial/Serious] The title is relatively ill-chosen. The 
specification indeed is about a system and environment framework, and 
this title would be fine within the sole context of the  MMI WG's 
Technical Reports website, but that is not the case. Within the context 
of W3C's TR space, "System and environment Framework" is way too vague. 
Is that a framework of system and environment for the whole web?

Think of it in terms of "specification title namespace". Fortunately, 
for example, XML events and DOM level {2,3} Events do not collide 
because they specify their naming space clearly.

I therefore strongly suggest that the document should be renamed:
"Multimodal Interaction Framework: System and Environment"


2* [Editorial/Suggestion] The Abstract starts by talking about the MMI 
WG. And while the WG should be thanked for their work, starting the 
document by mentioning it is perhaps not appropriate. The WG will not 
exist as long as the specification, and besides, while reading the 
abstract, the reader wants to know what the specification is about, and 
could care less who made it...


3* [Editorial] The specification has a few typos here and there. 
Appending ",spell" to the URI of any document on the W3C site (not 
necessarily when setting it up on /TR/) will pass the document to a 
spell checker.


4* [Editorial/Suggestion] The document introduces a lot of acronyms and 
specific terms. A glossary would be a very useful addition to the spec.


5* [Conformance/Suggestion] Have you considered other possible orders 
for the sections? I found that it too several readings just to get the 
"big picture. One possible reason for that is that the spec is not 
organized in a top-to-bottom structure, with a first section detailing 
the model, and then diving deeper into the details (properties, 
datatypes, etc).


6* [Conformance] There is a brief mention of other specifications this 
spec depends on, but in a rather casual way. A specific section stating 
dependencies and interactions with other specs would be clearer.


7* [Conformance/Serious] [related to 5 and 6] What is the conformance 
model for this specification? hints are scattered here and there in the 
document, pointing to such documents as the MMI Note, DOM specs, IDL, 
etc. The addition of a clear conformance model would not only make the 
implementation of sysenv easier, it will certainly have a strong 
influence on the way the document matures.


8* [Conformance] Some sections are already well marked as informative, 
others mention the existence of informative examples. Clearly and 
consistently marking each section as informative or normative could be 
a good (and easy for the editors to provide) implementation help.


9* [Conformance] [related to 8] Attributes are generally "defined" with 
both machine-readable and human readable text. Which is the normative, 
which is the informative version of that particular information?


10* [Editorial/Suggestion][related to 7] The introduction is rather 
long, and the "assumptions" section (which looks very much like a 
beginning of principles and conformance model section) is, on the other 
hand, quite short. You could merge-split these two.


11* [Editorial] in 1-Introduction, the document states that DTMF is a 
keypad type. For the non-expert that I am, DTMF stood for signal type, 
which happens to be interfaced, on a lot of devices, with a certain 
type of keypad. If the keypad is also named DTMF, you can forget this 
comment, otherwise, the shortcut seems a bit bold.


12* [Editorial] Section 4-Interfaces for Properties starts with "This 
section describes how to determine whether a device supports a given 
property, or named set of properties". Does it, really? I see that the 
section mainly lists properties, but not "how to determine whether a 
device supports" them.

Hope this helps.
Kind regards,
-- 
olivier Thereaux - W3C / QA / IG & Tools
Received on Monday, 30 August 2004 04:49:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:33 UTC