W3C home > Mailing lists > Public > www-multimodal@w3.org > June 2010

[ink] Comments on LC 20100527

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 16 Jun 2010 18:51:14 +0200
To: www-multimodal@w3.org
Message-ID: <1276707074.4420.419.camel@altocumulustier>

Going through the Last Call Working Draft of InkML dated May 27 2010, I
found the following potential issues:
* the abstract says that InkML is for "in the W3C Multimodal Interaction
Framework as proposed by the W3C Multimodal Interaction Activity"; it
looks to me that it is not restricted to that usage, so I would remove
that phrase

* MathML 2.0 is used as part of the possible content of the <mapping>
element, but MathML is not part of list of references in Appendix C

* InkML defines effectively a subset of MathML — has this been
discussed/approved by the Math Working Group?

* the XML Schema linked from Appendix E allows for any MathML content,
not the one defined in the spec; it would probably be worth refining it

* the examples don't include the namespace declaration, even when they
include the <ink> element — I think they should

* the mime type registration says that InkML is extensible; is this a
reference to the open content model of annotationXML, or something else
as well? It might be worth highlighting the extensibility mechanism as a
specific subsection of the spec

* there is no conformance section 

* the grammar for the <trace> data quotes the quote sign between quotes
(in the difference_order production); that doesn't sound right; while
ISO EBNF is listed in the references section, it's not
linked/highlighted from the EBNF usage in the spec

* the examples in 3.2.1 and in 6.3.1 use "<trace id=...>" instead of
"<trace xml:id=...>"; likewise for the <canvas> example in 5.1 (I
suggest validating the examples with the XML Schema to ensure they're

* the example in 4.2.1 is not well-formed (<channelProperty> is not

* that same example uses an undefined <resolution> element — I guess
<channelProperty name="resolution"> was meant?

* that same example has a <traceFormat> element with an href attribute —
that's not part of the spec either

* the activeArea example in 4.2.4 has a trailing semi-colon

* the existence of DefaultCanvas (5.3) means that this id cannot be used
anywhere else as id in an InkML document ; that should probably
highlighted much more visibly; wouldn't it make more sense to have that
URI a non-relative URI, but a well-known URI à la
http://www.w3.org/ns/inkml/canvas#default ?

* the example of 6.1.2 is not well-formed (<bind> is not closed)

* the XML schema requires at least one inkSource element per <context>
element, when the spec doesn't (it's missing a minOccurs="0")

* the example of 6.3.1 has href attribute for traceView instead of
(presumably) traceDataRef

* the second example of 6.3.2 has an extraneous apostrophe in the
encoding attribute of the first annotationXML element

* that same example probably should put the <html> element in the html

* that same example is not well-formed due to an extraneous </div>

* the first example in 7.1 is not well-formed (<channel> elements not

* the schema forbids having more than one <channel> element with the
name "X" (or "Y") — that seems like a bug (or the first example in 7.1
is buggy)

* the third example in 7.1 uses "#context2" and "#penA" as  ids, which
are not valid ids (the # should be removed)

* the fourth example in 7.1 is not well-formed (the first two <trace>
elements are closed twice)

* the two examples in 7.3 use canvasTransform instead of
canvasTransformRef as an attribute

Received on Wednesday, 16 June 2010 16:51:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 June 2010 16:51:25 GMT