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

[ink] Responses to your comments on the W3C InkML Working Draft

From: Tom Underhill <Tom.Underhill@microsoft.com>
Date: Mon, 30 Aug 2010 00:14:00 +0000
To: Dominique Hazael-Massieux <dom@w3.org>
CC: "www-multimodal@w3.org" <www-multimodal@w3.org>, "smwatt@gmail.com" <smwatt@gmail.com>
Message-ID: <4045AB4EE43EB94C9508DDC490FA9F7127BED262@DF-M14-02.exchange.corp.microsoft.com>
Thank you for your comments on the InkML Working Draft.   The InkML working group has considered each of your comments and have recorded them and our responses in the InkML 1.0: Working Draft Disposition of Comments document (http://www.w3.org/2002/mmi/2010/InkML/ED-InkML-20100811/inkml-disp.xml ).   A copy of each of your comments and our responses are also copied below.
	
The latest draft of the InkML specification can be found here: http://www.w3.org/2002/mmi/2010/InkML/ED-InkML-20100811/ .

The original copies of your comments made on 2010-06-16 are here: http://lists.w3.org/Archives/Public/www-multimodal/2010Jun/0002.html

Thank you for your input!

The InkML Editors:
	Tom Underhill, Microsoft
	Stephen M. Watt, University of Western Ontario

============
Comment #152:
------------
* 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
------------
Resolution: accepted
------------
Changed to:

This document describes the syntax and semantics for the Ink Markup Language.  The Ink Markup Language serves as the data format for representing ink entered with an electronic pen or stylus. The markup allows for the input and processing of handwriting, gestures, sketches, music and other notational languages in applications. It provides a common format for the exchange of ink data between components such as handwriting and gesture recognizers, signature verifiers, and other ink-aware modules.  It may be used in the W3C Multimodal Interaction Framework as proposed by the W3C Multimodal Interaction Activity. 
============
Comment #153:
------------
* 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
------------
Resolution: accepted
------------
Added:

[MATHML2]
Mathematical Markup Language (MathML) Version 2.0 (Second Edition), David Carlisle, Patrick Ion, Robert Miner, Nico Poppelier, Editors, W3C Recommendation, 21 October 2003, http://www.w3.org/TR/2003/REC-MathML2-20031021/ . Latest version http://www.w3.org/TR/MathML2/ .

to Appendix C.
============
Comment #154:
------------
* InkML defines effectively a subset of MathML - has this been discussed/approved by the Math Working Group?
------------
Resolution: accepted
------------
Yes, we have been in contact with the MathML WG.
============
Comment #155:
------------
* 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
------------
Resolution: accepted
------------
The inkml.xsd now includes an inkml-mathml2-subset.xsd that defines the subset of MathML supported by inkml.
============
Comment #156:
------------
* the examples don't include the namespace declaration, even when they include the <ink> element - I think they should
------------
Resolution: accepted
------------
Added xmlns="http://www.w3.org/2003/InkML" to all <ink> examples.
============
Comment #157:
------------
* 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
------------
Resolution: rejected
------------
Overview section describes including other xml to Inkml via <annotationXML> as does the <annotationXML> section itself.
============
Comment #158:
------------
* there is no conformance section
------------
Resolution: accepted
------------
A conformance section 8 has been added.
============
Comment #159:
------------
* 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
------------
Resolution: accepted
------------
Added EBNF link and changed the grammar to:

  difference_order ::= ("!" | "'" | '"')

That's apos-quote-apos instead of quote-quote-quote.  This conforms to the EBNF ISO spec.
============
Comment #160:
------------
* 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 correct)
------------
Resolution: accepted
------------
Changed all instances of id= to xml:id=.    Also removed whitespace before and after '=' in xml examples which is not valid xml.
============
Comment #161:
------------
* the example in 4.2.1 is not well-formed (<channelProperty> is not closed)
------------
Resolution: accepted
------------
Closed the <channelProperty/> element.
============
Comment #162:
------------
* that same example uses an undefined <resolution> element - I guess <channelProperty name="resolution"> was meant?
------------
Resolution: accepted
------------
Changed it to:
      <channelProperty 
         channel="F" 
         name="resolution"
         value="1024"
         units="dev"/>
============
Comment #163:
------------
* that same example has a <traceFormat> element with an href attribute - that's not part of the spec either
------------
Resolution: accepted
------------
It is an error.  I changed the example to be <traceFormat>.</traceFormat>.

I found another error is 6.3.1 where <traceView> is using href.  I changed it from:
   <traceView href="#tg1">
to
   <traceView traceDataRef="#tg1">
============
Comment #164:
------------
* the activeArea example in 4.2.4 has a trailing semi-colon
------------
Resolution: accepted
------------
removed the semicolon.
============
Comment #165:
------------
* 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 ?
------------
Resolution: rejected
------------
There are already implementations the use "#DefaultCanvas"
============
Comment #166:
------------
* the example of 6.1.2 is not well-formed (<bind> is not closed)
------------
Resolution: accepted
------------
Closed the <bind/> element.
============
Comment #167:
------------
* the XML schema requires at least one inkSource element per <context> element, when the spec doesn't (it's missing a minOccurs="0")
------------
Resolution: accepted
------------
Either change <context> CONTENTS in section 4.1 so that inkSource? Changes to inkSource; or add minOccurs="0" to XSD.   Did the later.
============
Comment #168:
------------
* the example of 6.3.1 has href attribute for traceView instead of (presumably) traceDataRef
------------
Resolution: accepted
------------
Already changed it to traceDataRef above.
============
Comment #169:
------------
* the second example of 6.3.2 has an extraneous apostrophe in the encoding attribute of the first annotationXML element
------------
Resolution: accepted
------------
removed the extra apos.
============
Comment #170:
------------
* that same example probably should put the <html> element in the html namespace
------------
Resolution: accepted
------------
Added xmlns="http://www.w3.org/1999/xhtml" to <html>
============
Comment #171:
------------
* that same example is not well-formed due to an extraneous </div>
------------
Resolution: accepted
------------
Removed extra <div> and fixed the indentation.
============
Comment #172:
------------
* the first example in 7.1 is not well-formed (<channel> elements not closed)
------------
Resolution: accepted
------------
Closed the <channel/> elements.
============
Comment #173:
------------
* 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)
------------
Resolution: rejected
------------
You may not have more than one <channel> with the same name within a <traceFormat>.
============
Comment #174:
------------
* the third example in 7.1 uses "#context2" and "#penA" as  ids, which are not valid ids (the # should be removed)
------------
Resolution: accepted
------------
Removed the # characters from the names
============
Comment #175:
------------
* the fourth example in 7.1 is not well-formed (the first two <trace> elements are closed twice)
------------
Resolution: accepted
------------
Fixed the double closure of the <trace> elements
============
Comment #176:
------------
* the two examples in 7.3 use canvasTransform instead of canvasTransformRef as an attribute
------------
Resolution: accepted
------------
Changed all instances of canvasTransform= to canvasTransformRef=.
Received on Monday, 30 August 2010 06:31:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 August 2010 06:31:30 GMT