- From: olivier Thereaux <ot@w3.org>
- Date: Mon, 30 Aug 2004 13:49:29 +0900
- 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