- 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