W3C

InkML 1.0: Last Call Disposition of Comments

This version:
2010-11-30
Editor(s):
Stephen Watt, University of Ontario
Tom Underhill, Microsoft

Abstract

This document details the responses made by the InkML subgroup of the Multimodal Interaction Working Group to issues against the first Last Call Working Draft (published on 23 October 2006) and the second Last Call Working Draft (published on 27 May 2010). Comments were provided by other W3C Working Groups and the public via the www-multimodal-request@w3.org (archive) mailing list.

Status

This document of the W3C's InkML Working Group describes the disposition of comments as of 30 November, 2010 on the first and the second Last Call Working Drafts of Ink Markup Language (InkML). it may be updated, replaced or rendered obsolete by other W3C documents at any time.

Table of Contents


1. Introduction

This document describes the disposition of comments in relation to Ink Markup Language (InkML) Version 1.0 (http://www.w3.org/TR/InkML/). The goal is to allow the readers to understand the background behind the modifications made to the specification. In the meantime it provides an useful check point for the people who submitted comments to evaluate the resolutions applied by the W3C's InkML Group.

In this document each issue is described by the name of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.

2. Summary

ItemCommentatorNatureResolutionCommenter's acceptance
2Al Gilman, WAI Protocols and Formats WG (2006-12-18)Clarification / Typo / Editorial AcceptedAccepted
14Al Gilman, WAI Protocols and Formats WG (2006-12-18)Change to Existing FeatureRejectedAccepted
18Al Gilman, WAI Protocols and Formats WG (2006-12-18)Technical ErrorAcceptedAccepted
20Al Gilman, WAI Protocols and Formats WG (2006-12-18)Change to Existing FeatureAcceptedAccepted
21Al Gilman, WAI Protocols and Formats WG (2006-12-18)Change to Existing FeatureAcceptedAccepted
28Al Gilman, WAI Protocols and Formats WG (2006-12-18)Change to Existing FeatureAcceptedAccepted
32Al Gilman, WAI Protocols and Formats WG (2006-12-18)Technical ErrorAcceptedAccepted
38Al Gilman, WAI Protocols and Formats WG (2006-12-18)Clarification / Typo / Editorial AcceptedAccepted
39Al Gilman, WAI Protocols and Formats WG (2006-12-18)Feature RequestAcceptedAccepted
46Al Gilman, WAI Protocols and Formats WG (2006-12-18)Change to Existing FeatureAcceptedAccepted
80Al Gilman, WAI Protocols and Formats WG (2006-12-20)Change to Existing FeatureAcceptedAccepted
199Charles Pritchard <chuck@jumis.com> (2010-06-30)Feature RequestRejectedAccepted
84David Carlisle, Math WG (2006-12-14)Feature RequestAcceptedAccepted
85David Carlisle, Math WG (2006-12-14)Clarification / Typo / Editorial AcceptedAccepted
86David Carlisle, Math WG (2006-12-14)Clarification / Typo / Editorial AcceptedAccepted
87David Carlisle, Math WG (2006-12-14)Change to Existing FeatureAcceptedAccepted
88David Carlisle, Math WG (2006-12-14)Clarification / Typo / Editorial AcceptedAccepted
99David Carlisle, Math WG (2006-12-14)Feature RequestRejectedAccepted
147David Carlisle, Math WG (2006-12-14)Change to Existing FeatureAcceptedAccepted
152Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Change to Existing FeatureAcceptedAccepted
153Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial AcceptedAccepted
154Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial AcceptedAccepted
155Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial AcceptedAccepted
156Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
157Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial RejectedAccepted
158Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial AcceptedAccepted
159Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
160Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
161Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
162Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
163Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
164Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
165Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial RejectedAccepted
166Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
167Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
168Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
169Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
170Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
171Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
172Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
173Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Clarification / Typo / Editorial RejectedAccepted
174Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
175Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
176Dominique Hazael-Massieux <dom@w3.org> (2010-06-16)Technical ErrorAcceptedAccepted
3Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
4Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
5Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorRejectedAccepted
6Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
7Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
8Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
9Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorRejectedAccepted
10Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
11Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
12Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
15Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
16Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
22Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
25Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
29Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorRejectedAccepted
33Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
34Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
40Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
41Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
47Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
48Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
49Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
50Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
51Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
55Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
59Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorRejectedAccepted
60Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
61Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
62Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
63Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
64Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
65Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
66Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
74Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
75Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
76Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
78Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
81Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
89Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
90Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
91Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
95Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
97Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
100Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
101Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
102Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureRejectedAccepted
104Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
105Grégory Pakosz, Vision Objects (2006-12-20)Change to Existing FeatureAcceptedAccepted
106Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
107Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
108Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
109Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
110Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial RejectedAccepted
111Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
112Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
113Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
114Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
115Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
116Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
117Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
118Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
119Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
120Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
121Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
122Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
123Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
124Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
125Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
126Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
127Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
128Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
129Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
130Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
131Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
132Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
133Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
134Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
135Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
136Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
137Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
138Grégory Pakosz, Vision Objects (2006-12-20)Technical ErrorAcceptedAccepted
139Grégory Pakosz, Vision Objects (2006-12-20)Clarification / Typo / Editorial AcceptedAccepted
143Grégory Pakosz, Vision Objects (2006-12-20)Feature RequestAcceptedAccepted
27Jonathan Chetwynd, SVG WG (2006-11-04)Change to Existing FeatureRejectedImplicitly accepted
148Jonathan Chetwynd, SVG WG (2006-11-04)Change to Existing FeatureAcceptedImplicitly accepted
149Jonathan Chetwynd, SVG WG (2006-11-04)Change to Existing FeatureRejectedImplicitly accepted
177Robert Vincenz <vincenz@snafu.de> (2010-06-09)Technical ErrorAcceptedImplicitly accepted
178Robert Vincenz <vincenz@snafu.de> (2010-06-09)Technical ErrorAcceptedImplicitly accepted
179Robert Vincenz <vincenz@snafu.de> (2010-06-09)Feature RequestRejectedImplicitly accepted
180Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
181Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
182Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
183Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
184Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted
185Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted
186Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
187Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
188Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
189Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
190Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted
191Robert Vincenz <vincenz@snafu.de> (2010-06-09)Feature RequestRejectedImplicitly accepted
192Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted
193Robert Vincenz <vincenz@snafu.de> (2010-06-09)Technical ErrorAcceptedImplicitly accepted
194Robert Vincenz <vincenz@snafu.de> (2010-06-09)Feature RequestRejectedImplicitly accepted
195Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted
196Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial AcceptedImplicitly accepted
197Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted
198Robert Vincenz <vincenz@snafu.de> (2010-06-09)Clarification / Typo / Editorial RejectedImplicitly accepted

2.1 Clarifications, Typographical, and Other Editorial

Issue 2

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Orphan 'The'

In: http://www.w3.org/TR/2006/WD-InkML-20061023/#OverviewElements

there is an orphan sentence fragment 'The' at the end of the paragraph before the example.

Resolution: Accepted

Removed the orphaned 'The'.

Email Trail:

Issue 38

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Extra 's' in values

In:
<quote
cite= http://www.w3.org/TR/2006/WD-InkML-20061023/#traceContents >

Additionally, wsp may occur anywhere except within a decimal or hex and must occur if required to separate two values.
</quote>

There is a redundant terminal 's' in the last word.

Resolution: Accepted

Removed the extra 's'.

Email Trail:

Issue 85

From David Carlisle, Math WG (2006-12-14):

Typo, namespace

There is a (presumably non normative) example which does mention the mathml namespace but it is

<mapping type="mathml" m:xmlns="http://www.w3.org/1998/Math/MathML">
<bind source="R" variable="r"/>
<bind source="OTh" variable="theta"/>
<math xmlns="http://www.w3.org/1998/Math/MathML">


m:xmlns is presumably a typo for xmlns:m but that in fact the whole
attribute can be deleted as no m: prefix is actually used, and the
mathml namespace is introduced again on the math element.

Resolution: Accepted

Removed the m:xmlns="http://www.w3.org/1998/Math/MathML".

Email Trail:

Issue 86

From David Carlisle, Math WG (2006-12-14):

Typo

Also <times> should be <times/> (twice) in the example mathml mapping.

Resolution: Accepted

Changed <times> to <times/>

Email Trail:

Issue 88

From David Carlisle, Math WG (2006-12-14):

Typo

The example of mathml in the <bind> element description again has a typo in the namespace declaration

<mapping xml:id="m06" type="mathml">
<bind type="setvar" target="X" variable="Q" />
<math mlns="[ http://www.w3.org/1998/Math/MathML ]">
missing x.

Resolution: Accepted

Changed mlns= to xmlns=.

Email Trail:

Issue 153

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 154

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 155

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 157

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 158

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* there is no conformance section

Resolution: Accepted

A conformance section 8 has been added.

Email Trail:

Issue 165

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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

I have added language to the spec to explicitly describe the id "DefaultCanvas" as being reserved and therefore unavailable to be used as the id of a user defined <canvas> element. The same applies to the "DefaultContext" reserved id, so I also added language for that id. The "DefaultTraceFormat" id already had language describing it as reserved.

The last paragraph in section 4.5 changed to:
The default context may be explicitly specified using the URI "#DefaultContext". The id "DefaultContext" is therefore reserved and may not be used as the id of a user defined <context> element.
The last paragraph in section 5.3 changed to:
The default canvas may be explicitly specified using the URI "#DefaultCanvas". The id "DefaultCanvas" is therefore reserved and may not be used as the id of a user defined <canvas> element.

Email Trail:

Issue 173

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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

The XSD is in error. I removed the key/keyref from the XSD.

Email Trail:

Issue 33

From Grégory Pakosz, Vision Objects (2006-12-20):

relativeTo -> respectTo

- rename: channelDef --> channel, relativeTo --> respectTo
(in text and example)

>>> Fixed

Some references to “relativeTo” still present in text and example.

Resolution: Accepted

Changed the remaining instances of 'relativeTo' to 'respectTo'.

Email Trail:

Issue 110

From Grégory Pakosz, Vision Objects (2006-12-20):

Headers ids naming convention is inconsistent.

Resolution: Rejected

There are external links that refer to the #id's. Changing the naming now would break external links.

I did make a concerted attempt to clean up the id’s to make them more consistent, but found several external docs that referenced the id’s (our own InkML XSD is one example, Microsoft Office implementation documentation is another one). The instance in comment #126 I chose to rename because I couldn’t find any external references to it and it didn’t match the human readable name of the section anymore.

Email Trail:

Issue 111

From Grégory Pakosz, Vision Objects (2006-12-20):

This fourth version of the Working Draft includes a few conceptual changes to simplify the definition while achieving greater expressive power. It also contains many small changes of details to make element and attribute use uniform accross the the definition to make it easier to learn and simpler to process.
Should be "across the" (see Status of this document).

Resolution: Accepted

Fixed "accross" to "across".

Email Trail:

Issue 112

From Grégory Pakosz, Vision Objects (2006-12-20):

Canvas transformations allow ink from different devices to combined and manipulated by multiple parties.
"be" is missing: "Canvas transformations allow ink from different devices to be combined and manipulated by multiple parties" (see 1.2 Elements).

Resolution: Accepted

Added missing "be" to sentence.

Email Trail:

Issue 118

From Grégory Pakosz, Vision Objects (2006-12-20):

units = xsd:string
The units in which the values of the channel are xpressed (numerical channels only).
Required: no, Default: none
Should be "expressed" (see 3.1.3 <channel> element).

Resolution: Accepted

Changed "xpressed" to "expressed".

Email Trail:

Issue 120

From Grégory Pakosz, Vision Objects (2006-12-20):

<channel name="T"
type="integer"
units="ms"
respectTo="#ts1"/>
Fix indentation (see 3.1.7 Time Channel).

Resolution: Accepted

Fixed the indentation in the <channel name="T"> example.

Email Trail:

Issue 123

From Grégory Pakosz, Vision Objects (2006-12-20):

Additionally, wsp may occur anywhere except within a decimal or hex and must occur if required to separate two valuess.
Should be "values" (see 3.2.1 <trace> element contents).

Resolution: Accepted

Changed "valuess" to "values"

Email Trail:

Issue 126

From Grégory Pakosz, Vision Objects (2006-12-20):

[ http://www.w3.org/TR/2006/WD-InkML-20061023/#traceAggregate 3.3 Trace Collections section]'s id is "#traceAggregate", change to "#traceCollections".

Resolution: Accepted

Changed "#traceAggregate" to "#traceCollections"

Email Trail:

Issue 128

From Grégory Pakosz, Vision Objects (2006-12-20):

The <inkSource> element will allow specification of:
1. Manufacturer, model and serial number (of a hardware device)
1. Text description of source, and reference (URI) to detailed or additional information
1. Trace format - regular and intermitent channels reported by source
1. Sampling rate, latency and active area
1. Additional properties of the device in the form of name-value-units triples
1. Properties of individual channels
Should be "intermittent" (see 4.2.1 <inkSource> element).

Resolution: Accepted

Changed "intermitent" to "intermittent"

Email Trail:

Issue 134

From Grégory Pakosz, Vision Objects (2006-12-20):

If the canvas tranform is given as an affine map of full rank, then it may be inverted numerically
Should be "transform" (see 5 Canvases).

Resolution: Accepted

Changed "tranform" to "transform"

Email Trail:

Issue 135

From Grégory Pakosz, Vision Objects (2006-12-20):

If the type attribute has value mathml then the content is a subset of MathML restricted to the following subset of Content MathML 2.0 elements defining arithmetic on integers, real numbers and boolean values:
• Numbers: cn
• Named constants: exponentiale, pi, true, false
• Identifiers: ci. These must be associated to channels using
a <bind> element.
• Arithmetic: plus, minus, times, divide, quotient, rem, power,
root, min, max, abs, floor, cieling
• Elementary classical functions: sin, cos, tan, arcsin, arccos,
arctan, exp, ln, log
• Logic: and, or, xor, not
• Relations: eq, neq, gt, lt, geq, leq
• Operator application: apply

Are these ones correct ? Shouldn't it be exponential and ceiling? (see 6.1.1 <mapping> element)

Resolution: Accepted

Changed "exponentiale" to "exponential, e" and changed "cieling" to "ceiling".

Email Trail:

Issue 137

From Grégory Pakosz, Vision Objects (2006-12-20):

The <annotation> element provides a mechanism for inserting simple textual descriptions in the ink markup. This may be use for multiple purposes.
Should be "This may be used for multiple purposes".

Resolution: Accepted

Changed "use" to "used".

Email Trail:

Issue 139

From Grégory Pakosz, Vision Objects (2006-12-20):

Replace all "refered" occurrences by "referred", found several times.

Resolution: Accepted

Changed all "refered" to "referred".

Email Trail:

Issue 180

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.1.1 <traceFormat> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#traceFormat
In the last line'The default trace format may be explicitly specified using the URI "#DefaultTraceFormat". The application defines the default trace format.'This Element have no URI as attribute or content so do you mean the ID or is this URI used in a different place and mean a not defined traceFormat definition? If this is a URI that is used in a other Element pleas name them or move this line to this Elements description.

Resolution: Accepted

Clarified the paragraph:

The <context> element may use the traceFormatRef attribute to refer to a <traceFormat> by it's id. If no <traceFormat> is specificed in an InkML file, an application defined default trace format is used. The default trace has the reserved id "DefaultTraceFormat" and may be explicitly referenced using the URI "#DefaultTraceFormat".

Email Trail:

Issue 181

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.1.2 <intermittentChannels> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#intermittentChannels
To avoid misinterpretation you MUST define that the intermittentChannels MUST NOT be followed by a normal channel definition. Because in this cases the order is not clear. I also recommit to change this Element definition place to be after the one of the channel Element.

Resolution: Accepted

I swapped the order of sections 3.1.2 and 3.1.3 -- that makes more sense. The Contents of <traceFormat> does indicate that intermittentChannels must appear after channels, as does the XSD, as does the langugages of section 3.1.3 (the new section 3.1.3) which says:

"The <intermittentChannels> section is optional and must appear after the regular <channel> elements (if any) within a <traceFormat> element.
3"

Email Trail:

Issue 182

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.1.3 <channel> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#channel
Is the name attribute value case sensitive interpreted?

Resolution: Accepted

Yes, they are case sensitive. I added language to say they're case sensitive.

Email Trail:

Issue 183

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

The most pens give a value that DO NOT present a mass but a relative value(0 for not pressed up to a a max value like 256 or 1024 that represent the max measured press or more). So why is g(gram) used? I recommit to use a percentage value or a decimal from .0 to 1. As alternate split it to F for force with percentage or .0 to 1 and G for a mass in gram.

Resolution: Accepted

Yes, that makes a lot of sense since I have never seen a device that actually uses a mass to record force, it’s a always a arbitrary value range. Even though we specify a default, a 'F' channel may still be defined with a particualar unit such as grams, newtons, etc.

Email Trail:

Issue 184

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

For the orientation attribute is what is +ve? Increase or decrease?

Resolution: Rejected

+ve' is increasing for a particular direction, depending on X,Y, or Z as described in the channel table:

X coordinate. This is the horizontal pen position on the writing surface, increasing to the right for +ve orientation.
Y coordinate. This is the vertical position on the writing surface, increasing downward for +ve orientation.
Z coordinate. This is the height of pen above the writing surface, increasing upward for +ve orientation.

Email Trail:

Issue 185

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.1.5 Color Channels -> http://www.w3.org/TR/2010/WD-InkML-20100527/#color
What is the value range of CR, CG, CB, CC, CM, CY and CK or is a mapping element required for the range? This Range SHOULD be definable because the Color-space size for professional graphic programs can be 8, 10, 12, 16, 32 bit per channel(e.g. http://www.cinepaint.org/).Maybe the Color channels should be defined more free to allow more color-spaces like YUV, CIE, ...

Resolution: Rejected

Yes, a mapping would define the actual min/max values for each channel (0-255, or 0.0-1.0, etc.). Since user defined channels are possible, other color spaces can be application defined.

Email Trail:

Issue 186

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.1.7 Time Channel -> http://www.w3.org/TR/2010/WD-InkML-20100527/#time
The "(see Time Channel)" is a self-reference. Why? Do you mean the timestamp element?

Resolution: Accepted

Removed the useless reference. It was a hold over from when this paragraph lived elsewhere.

Email Trail:

Issue 187

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

As with the other predefined channels, the meaning of the integer or decimal values recorded by the time channel in a given trace is defined by the <inkSource> information associated with the trace's <traceFormat>.'This is the first time the inSource element is named. Which other predefined channels are affected?

Resolution: Accepted

The meaning is really defined by the <traceFormat>. <traceFormats> may live in an <inkSource>. Earlier versions of the spec may have requried <traceFormats> in <inkSources> and hence this language. I reworded it to:

As with the other predefined channels, the meaning of the integer or decimal values recorded by the time channel in a given trace is defined by the trace's associated <traceFormat>. In the case of the time channel, its <channel> element contains both a units and respectTo attribute.

Email Trail:

Issue 188

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.1.9 Specifying Trace Formats -> http://www.w3.org/TR/2010/WD-InkML-20100527/#specifying'
Thus, in the simplest case, an InkML file may contain nothing but <trace> elements.'
That not correct. As you wrote in 1.2'All content of an InkML document is contained within a single <ink> element.' This is also required to be XML conform. What you mean is:"Thus, in the simplest case, an InkML file may contain nothing but <trace> elements insite a <ink> element."

Resolution: Accepted

Changed to:

Thus, in the simplest case, an InkML file may contain nothing but <trace> elements within an <ink> element.

Email Trail:

Issue 189

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.2.1 <trace> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#trace'Extended Backus-Naur Form (EBNF)'There is no reference to the RFC or other document that defines EBNF and the one provided is not this good.
trace ::= point ("," point)* ","? wsp*
point ::= (wsp* value)+ wsp*
value ::= difference_order? wsp* "-"? wsp* number | "T" | "F" | "*" | "?"'
This is wrong. Because this allows:
1) negative values for coordinate values
2) a point to be only made with one value
3) you can prefix the T F * and ? with -
4) write two values without space( 1 2 -> 12).
you have wrote this already after the EBNF, but why using EBNF and then tell the reader to ignore it?
5) difference order for F T * and ?6) ? for regular values
7) mix of regular and intermittent values

Resolution: Accepted

Changed the EBNF reference to:

The following grammar defines the syntax of the data that appears within a <trace> element. It is described using the subset of Extended Backus-Naur Form defined in the Notation section of the Extensible Markup Language (XML) 1.0 (Fourth Edition) specification [EBNF]. This subset of EBNF includes the following notation:

It is recongnized that the grammar presented is not perfect, but is the closest validation possible using BNF and still remain brief and human readable.

Email Trail:

Issue 190

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

If the continuation attribute is not present, is then the trace presenting a complete one?
In the case of a trace with a continuation attribute with "begin" or "middle" is followed by a trace without continuation, how is this to interpret or is this not allowed? Must a "multi trace" finished/closed with a trace element with a continuation attribute with the value "end"?

Resolution: Rejected

Yes, if there is no continutation attribute, then the trace is a self-contained trace.

The relative order of <trace> elements is not relevent. As the spec states, if a continuation attribute is present, and is "middle" or "end", it must have a priorRef attribute that references the prior trace.

a multi-trace doesn't have to have an explicit "end" trace. Multi-trace components don't necessarily have to in the same <ink> document. A possible application could be a "stream" of traces coming from a server to a client, in chunks -- each chunk being a seperate <ink> document. the order that the chunks arrive at the client could come in any order. The client would assemble the mulit-trace into a single trace as it receives the chunks.

Email Trail:

Issue 192

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

'Regular channels may be reported as explicit values, differences, or second differences: ...'What is a second difference? Does this mean that a second difference is refer to the same as a preceding difference or to the difference?

Resolution: Rejected

Its another way of saying it’s a "first order derivative" or "second order derivative". Or, no difference == absolute coordinate, first order == velocity, second order == acceleration.

Email Trail:

Issue 195

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

In the table that explain the example is something wrong on row 3("7"-8) or 4(3-5). I can't say which one because the second difference is not clear.If the second difference is the difference to the difference than is row 4 wrong(3-5) or there is no need for a second difference because this is the same as a numeric value.If the second difference is the difference to the value before the difference, then the 3th row is wrong("7"-8 | 1132 | 18424 | ...). In the same table every thing is the difference to the previews values and not the absolute values. But i can't see why this is so. Is the default to interpret the values relative? Then the example in 1.2 is wrong because there is the values interpreted as absolute coordinates.

Resolution: Rejected

It is correct. The first difference is a velocity (vx, vy), the second difference is an acceleration (dvx, dvx).

The first row is an absolute x,y pair: 1125, 18432.
The second row is a first order derivative, or a velocity, or change in value from the previous row. So 1125+23=1148, 18432+43=18475.
The third row (and all subsequent rows) are second order derivatives, or accelerations, or changes in velocity from the previous row. So 1148+(23+7)=1178, 18475+(43+-8)=18510.
and so on down the table.

Email Trail:

Issue 196

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

'Note: see Appendix A Implementation Guidelines for information about reducing file or stream size.'Appendix A is "Acknowledgements". You mean Appendix B.

Resolution: Accepted

Changed the reference from Appendix A to Appendix B.

Email Trail:

Issue 197

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

3.3.2 <traceView> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#traceViewElement
In the example the cascades of tracegroup elements is keep as in the origin. But i can't see this in the description. Must the cascades keep as in the source? the second traceview element of L3 has the "4:1:1" value for the to attribute. In the description under the example is "4:1:1:2" written, which is right for the given output.

Resolution: Rejected

You are correct. No clarification needed in spec.

Email Trail:

Issue 198

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

I#m not sure what is with a 0 in a to or from attribute value:
e.g.<ink><trace xml:id="t1">1 2, 3 4, 5 6</trace><traceView traceDataRef="t1" to="0:2" /></ink>
what is right?
1) it's not right because the index starts with 1
2) <trace> 1 2, 3 4</trace>
3) <trace xml:id="t1">1 2, 3 4, 5 6</trace>

If it is 1 the example in the Draft is right, but you cant select values in a document with only one ink, one trace and traceView elements.
The 2 mean its not a consistent numbering(elements can start with 0 but points start with 1).
3 means the examples in the Draft are wrong, but you can select points in my example and its a consistent numbering.

Resolution: Rejected

A '0' in either the to or from attribute is illegal. This section explicilty states that the indexes are 1-based. 0 is an error.

Email Trail:

2.2 Technical Errors

Issue 18

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

traceFormat has? associated inkSource

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023


<quote
cite="http://www.w3.org/TR/2006/WD-InkML-20061023/#time">

The time channel can be specified as either a regular or intermittent
channel. When specified as a regular channel, the single quote prefix can be used to record incremental time between successive points.
Otherwise, the value of the time channel for a given sample point is
defined to be the timestamp of that point in the units and frame of
reference specified by its corresponding <inkSource> description
(more precisely, by the <traceFormat> element for the channel).

As with the other predefined channels, the meaning of the integer or
decimal values recorded by the time channel in a given trace is
defined by the <inkSource> information associated with the trace's
traceFormat. In the case of the time channel, its <channel> element
contains both a units and respectTo attribute.

</quote>

There is no provision through a sub-element or attribute to cite an
associated inkSource from the traceFormat element. These references to "its corresponding <inkSource> description" or "the <inkSource> information associated with the trace's traceFormat" appear to refer to an association that the format fails to construct.

What gives?

Resolution: Accepted

Rephrasing the documentation
From : '....Otherwise, the value of the time channel for a given sample point is defined to be the timestamp of that point in the units and frame of reference specified by its corresponding <inkSource> description (more precisely, by the <traceFormat> element for the channel)'
To: 'The Value of the time channel for a given sample point is defined to be the timestamp of that point in the units and frame of reference specified by the 'respectTo' attribute of the Time Channel that is defined in the associated TraceFormat of the trace.'

Email Trail:

Issue 32

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Width specification may be ambiguous

The direction of a trace through a sample point is undefined. You only have a discrete sequence of Cartesian samples.

Better to describe traces with 'width' data as the envelope of a sequence of circular dots of diameter given by the 'width' data. The trace generated by a circular brush of varying diameter.

Resolution: Accepted

Changed the definition of ‘Width’ to “It is the diameter of the larger circle that can be inscribed within the trace locus.”

Email Trail:

Issue 156

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 159

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 160

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 161

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

Closed the <channelProperty/> element.

Email Trail:

Issue 162

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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"/>

Email Trail:

Issue 163

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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">

Email Trail:

Issue 164

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

removed the semicolon.

Email Trail:

Issue 166

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

Closed the <bind/> element.

Email Trail:

Issue 167

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 168

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

Already changed it to traceDataRef above.

Email Trail:

Issue 169

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 170

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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>

Email Trail:

Issue 171

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

Removed extra <div> and fixed the indentation.

Email Trail:

Issue 172

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

Closed the <channel/> elements.

Email Trail:

Issue 174

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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

Email Trail:

Issue 175

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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

Email Trail:

Issue 176

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

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

Resolution: Accepted

Changed all instances of canvasTransform= to canvasTransformRef=.

Email Trail:

Issue 3

From Grégory Pakosz, Vision Objects (2006-12-20):

Application to handwriting recognition
<<1. Overview, Paragraph 2 and 4 >>
It is true that InkML allows the capture of ink as the user composed it, however in the typical case of handwriting recognition, ink itself is barely usable. Another valuable piece of information is the conditions in which the ink has been written: what the user was supposed to write: a name, a date, a phone number? what is the language? was the handwriting zone constrained: boxes, lines? etc.

Resolution: Accepted

Rephrased to explicitly say that the Digital Ink data can be represented in InkML format and it does not intend to provide support for capturing other information like the type of the data and type of the handwriting zone and etc. Added to the last paragraph: "It is not within the designed of InkML to describe and store semantic information, such as the plain text of ink recognized as handwriting. Nor is it a goal of InkML to store the contextual information about the ink, such as what kind of field in a form where ink was written. "

Email Trail:

Issue 5

From Grégory Pakosz, Vision Objects (2006-12-20):

Ink Messaging: Application for mobile device users
My opinion is that XML is generally speaking way too verbose for mobile application usage: anything that is XML based does not suit synchronous/streaming mobile scenarios because of the weight of XML parsers and the verbosity of the data.

Resolution: Rejected

We have XML parsers for Win CE and J2ME platforms. We have support for issuing SOAP request to Web services from hand held.

Email Trail:

Issue 7

From Grégory Pakosz, Vision Objects (2006-12-20):

Data Entry for Electronic form filling in keyboard less devices
InkML in itself has no value proposition for digital form processing solutions: it offers no markup that targets the structure of a digital form like "here is a boxed field that is composed of 10 boxes in which the user is supposed to write his last name" ... As a consequence, you need to introduce additional markup that is likely to be application specific and thus fails to answer interoperability needs.

Resolution: Accepted

Agreed, below is the revised language in section 1.1

Electronic Form-Filling

In support of natural and robust data entry for electronic forms on a wide spectrum of keyboard-less devices, a handwriting recognition engine developer may define an API that takes InkML as input for fields of the form.

Email Trail:

Issue 8

From Grégory Pakosz, Vision Objects (2006-12-20):

Pen Input and Multi modal Systems : Cross-modal redundancy use of InkML
Hmm right the InkML group is a subgroup of the MMI group
Apart from that, please don't see any offence but I find this paragraph rather useless to the understanding of InkML.

Resolution: Accepted

While it is obvious how InkML could participate in a multimodal framework, it was not made clear how it could benefit from a multimodal framework. We have therefore modified the multimodal paragraph in 1.1 to be more explicit how pen input can help multimodal environments and vice-versa.

Email Trail:

Issue 9

From Grégory Pakosz, Vision Objects (2006-12-20):

"A sequence of traces accumulates to meaningful units, such as characters, words or diagrams.”

This particular sentence could make the reader think that InkML is able to describe the structure of handwriting which is not the case at all. Indeed, there is no markup capable of describing a typical boxed field on a digital form: position and dimensions of the boxes and more importantly to which box belongs which trace.

Resolution: Rejected

By default, InkML do not have plan to support elements to describe characters/words/diagrams. But the application developer can achieve them using <annotation> or <annotationXML> elements under <traceGroup> (Semantic labeling traces as characters/words/diagrams).

Email Trail:

Issue 10

From Grégory Pakosz, Vision Objects (2006-12-20):

Finally, the InkML specification is limited in scope: It is currently oriented to fixed Cartesian coordinate systems, it does not support sophisticated compression of trace data, and it does not support non-ink events (although the later could be handled via annotations).

But would be application specific until a specification for a typical kind of annotation comes to light like it is the case for mathematical expressions represented by MathML markup.

Resolution: Accepted

Clarification was added to section 3.1.8 to make explicit how non-ink events, other coordinate systems, etc can be captured in traces.

Email Trail:

Issue 16

From Grégory Pakosz, Vision Objects (2006-12-20):

If no <traceFormat> is specified, a default encoding format of X and Y coordinates is assumed.
At this point of the document, is it clear that the default <traceFormat> is X then Y coordinates ? Somehow it would be good to emphasize the fact that coordinates are interleaved.

Resolution: Accepted

Rephrased to explicitly state the default traceFormat is X followed by Y

Email Trail:

Issue 22

From Grégory Pakosz, Vision Objects (2006-12-20):

Regular channels appear first in the <trace>, followed by any intermittent channels. Correspondingly, the <traceFormat> element contains an ordered sequence of <channel>s, giving the regular channels (if any), followed by an optional <intermittentChannels> section. The order of the coordinates in each point of a trace is determined by the order of the <channel> elements in the trace format, including those from the intermittent channels part.

The section refers to the concept regular or intermittent channel that was described in the introduction (see 3.1 Trace Formats). Maybe I'm too French for this writing style but I feel like the reader has to go back and forth and back again before having a chance to grasp the whole thing :D

Imagine you use the index to go to the <traceFormat> element definition, you read about channels but you have to scroll up to the introduction to know what they are. Then you scroll down where it talks about <channel>s that are followed by an optional <intermittentChannels> section which is described first!

Resolution: Accepted

Rephrased to clarifity order of regular channels vs intermittent channels.

Email Trail:

Issue 25

From Grégory Pakosz, Vision Objects (2006-12-20):

respectTo = xsd:anyURI

Specifies that the values are relative to another reference point.
Required: no, Default: none

The respectTo attribute specifies the origin for channels of integer or decimal type. For time channels, this is given as a URI for a <timestamp> element. For other dimensions the meaning is application-dependent.

I find this part of the <channel> element definition far from being clear (see 3.1.3 <channel> element): is it always an URI or only an URI when one wants to refer to a <timestamp> element? Please provide an example of the usage of the respectTo attribute applied to X and Y channels. Also, can the respectTo attribute be used when wanting to encode delta-x and delta-y coordinates?

The following example defines a time channel whose values for a given point are the relative to the timestamp refered to to by #ts1:
<channel name="T" type="integer" units="ms" respectTo="#ts1"/>

Although a usage example of the respectTo attribute is given as part of the time channel description (see 3.1.7 Time Channel), it is unclear to what this #ts1 relative URI corresponds to.

Resolution: Accepted

Rephrased to clarify respectTo attribute is the URI of a <timestamp> for time channels, but application defined for application defined channels.

Email Trail:

Issue 29

From Grégory Pakosz, Vision Objects (2006-12-20):

It is often useful to record the sine of this angle, rather than the angle itself, as this is usually more useful in calculations involving angles. The <mapping> element can be employed to specify an applied sine transformation.

At this point of the specification, it is unclear in which way it works. This is another example of back and forth reading (see 3.1.4 Orientation Channels).

Resolution: Rejected

Yes. The context of going for a <Mapping> is explained in the last paragraph of 3.1.3, i.e. before 3.1.4.

Email Trail:

Issue 34

From Grégory Pakosz, Vision Objects (2006-12-20):

The time channel can be specified as either a regular or intermittent channel. When specified as a regular channel, the single quote prefix can be used to record incremental time between successive points.

Again, this paragraph uses a feature that has not been introduced/detailed yet (see 3.1.7 Time Channel).

Resolution: Accepted

Added a reference to the Time Channel section.

Email Trail:

Issue 40

From Grégory Pakosz, Vision Objects (2006-12-20):

The appearance of a <traceFormat> element in an ink markup file both defines the format and installs it as the current format for subsequent traces (except within a <definitions> block).

At this point of the document, it is unclear whether or not a <traceFormat> element is allowed as a child of the <ink> element. Indeed the definition of the <ink> element specifies that it can contain <definitions>, <context>, <trace>, <traceGroup>, <traceView>, <annotation>, or <annotationXML> elements but no <traceFormat> elements. At this point, the reader knows how the <traceFormat> markup has to be written but does not have any clue of where it belongs (see 3.1.9 Specifying Trace Formats).

Resolution: Accepted

Added a reference to the Specifying Trace Formats section.

Email Trail:

Issue 41

From Grégory Pakosz, Vision Objects (2006-12-20):

If no <traceFormat> is specified, the following default format is assumed:
<traceFormat xml:id="DefaultTraceFormat">
<channel name="X" type="decimal"/>
<channel name="Y" type="decimal"/>
</traceFormat>

Does it mean that the "#DefaultTraceFormat" relative URI can be used as part of a traceFormatRef attribute or is it just an example of how the implicit trace format definition would look (see default trace format)?

Resolution: Accepted

Yes, the reserved id "DefaultTraceFormat" may be explicitly referenced using the uri "#DefaultTraceFormat". See section 3.1.1.

Email Trail:

Issue 59

From Grégory Pakosz, Vision Objects (2006-12-20):

The context element both provides access to a useful shared context (canvas) and serves as a convenient agglomeration of contextual attributes.

The context itself is not useful but at least it is convenient

(see 4.1 The <context> element)

Resolution: Rejected

The purpose of the <context> element explained in the specification is clear. There is no need for any conceptual change required in the documentation as action to the issue raised.

Email Trail:

Issue 60

From Grégory Pakosz, Vision Objects (2006-12-20):

xml:id = xsd:ID
The unique identifier for this context.
Required: no (yes for archival InkML), Default: none

I'm curious about the conditional part, how do you enforce this? How do you actually know the InkML document is intended for archival mode?
Comment: Muthu, 04/02/07
There is no way to identify the type of Ink Document as Archival/Streaming and hence not possible to enforce this rule. We may have to add a new attribute called ‘mode’ to Ink document??

Resolution: Accepted

Set the 'Required' constraint to 'no' on @xml:id (remove the exception for archival case).

Email Trail:

Issue 61

From Grégory Pakosz, Vision Objects (2006-12-20):

canvasRef = xsd:anyURI
The URI of a canvas element for this context.
Required: no, Default: "DefaultCanvas", or inherited from contextRef

traceFormatRef = xsd:anyURI
A reference to the traceFormat for this context.
Required: no, Default: default trace format, or inherited from contextRef

>>Is it "default trace format" or "DefaultTraceFormat"? I already asked the question but, could "#DefaultCanvas" and "#DefaultTraceFormat" relative URIs be used as references elsewhere, although they are implicitly defined?

Comment: Muthu, 04/02/07
Yes. It is explicitly specified in the case of Context(Section 4.5) as given below,
The default context may be explicitly specified using the URI "#DefaultContext".

inkSourceRef = xsd:anyURI
A reference to the inkSource for this context.
Required: no, Default: default capture device, or inherited from contextRef

>> What about default capture device?

Resolution: Accepted

It is a documentation issue; it will be fixed. "DefaultCanvas" to "#DefaultCanvas" and "default trace format" to "#DefaultTraceFormat".

Email Trail:

Issue 75

From Grégory Pakosz, Vision Objects (2006-12-20):

The default context may be explicitly specified using the URI "#DefaultContext".
It is explicitly specified that using the URI "#DefaultContext" is legal, however it is not specified for "#DefaultCanvas" or "#DefaultTraceFormat" (see 4.5 The Default Context).

Resolution: Accepted

the 2 missing URIs should be explicitly mentioned in the spec. Documentation has to be added for the same.

Email Trail:

Issue 76

From Grégory Pakosz, Vision Objects (2006-12-20):

A <canvas> element must have an associated <traceFormat>, which may either be given as a child element or referred to by a traceFormatRef attribute. The coordinate space of the canvas is given by the regular channels of the trace format and any intermittent channels are ignored.
When both are defined, which one prevails over the other? I would like it to be specified at this place of the document.

Resolution: Accepted

Either of them could be specified. If both of them are specified, then child element overrides the attribute.

Email Trail:

Issue 81

From Grégory Pakosz, Vision Objects (2006-12-20):

<canvas xml:id="DefaultCanvas">
<traceFormat>
<channel name="X" type="decimal" default="0" orientation="+ve" units="em"/>
<channel name="Y" type="decimal" default="0" orientation="+ve" units="em"/>
</traceFormat>
</canvas>
It is not specified whether or not referring to the default canvas using a "#DefaultCanvas" relative URI is legal.

Resolution: Accepted

It is legal. Issue is similar to issue #75 in Section4.5.

Email Trail:

Issue 109

From Grégory Pakosz, Vision Objects (2006-12-20):

Generally speaking, the markup contains various useless <span> elements.

Resolution: Accepted

Cleaned up the empty <span>'s

Email Trail:

Issue 113

From Grégory Pakosz, Vision Objects (2006-12-20):

Certain applications, such as collaborative whiteboards (where ink coming from different devices is drawn on a common canvas) or document review (where ink annotation from various sources is combined), will require ink sharing.
I would have used a plural form: where ink annotations from various sources are combined (see 1.2 Elements).

Resolution: Accepted

Changed "(where ink annotation from various sources is combined)" to "(where ink annotation from various sources are combined)".

Email Trail:

Issue 114

From Grégory Pakosz, Vision Objects (2006-12-20):

For ease of implementation, it is recommended that, in archival mode, referenced elements be defined inside a declaration block using the <definitions> element.
Not always recognized by non native English speakers. Maybe "For ease of implementation in archival mode, referenced elements should be defined inside a declaration block using the <definitions> element." would be easier to understand. Not a big issue anyway
(see 1.3 Exchange Modes).

Resolution: Accepted

Rephrased per recommendation in comment

Email Trail:

Issue 115

From Grégory Pakosz, Vision Objects (2006-12-20):

"Traces are the basic element used to record the trajectory of a pen as a user writes digital ink."
I would have written: "<trace> is the basic element used to record the trajectory of a pen as the user writes digital ink." (see 3 Traces and Trace Formatting).

Resolution: Accepted

Rephrased per recommendation in comment

Email Trail:

Issue 116

From Grégory Pakosz, Vision Objects (2006-12-20):

Traces generated by different devices, or used in differing applications, may contain different types of information. InkML defines channels to describe the data that may be encoded in a trace.
I guess a link is welcome here (see 3 Traces and Trace Formatting).

Resolution: Accepted

Added a link to Channel

Email Trail:

Issue 117

From Grégory Pakosz, Vision Objects (2006-12-20):

The <intermittentChannels> lists those channels whose value may optionally be recorded for each sample point.
I would have written: "The <intermittentChannels> element lists those channels whose value may optionally be recorded for each sample point." (see 3.1.2 <intermittentChannels> element)

Resolution: Accepted

Changed to "The <intermittentChannels> element lists those channels whose value may optionally be recorded for each sample point."

Email Trail:

Issue 119

From Grégory Pakosz, Vision Objects (2006-12-20):

The <mapping> element can be employed to specify an applied sine transformation.
I would have linked the <mapping> element with the corresponding section (see 3.1.4 Orientation Channels).

Resolution: Accepted

Added link to <mapping>

Email Trail:

Issue 121

From Grégory Pakosz, Vision Objects (2006-12-20):

Otherwise, the value of the time channel for a given sample point is defined to be the timestamp of that point in the units and frame of reference specified by its corresponding <inkSource> description (more precisely, by the <traceFormat> element for the channel).
I would have linked the <inkSource> element with the corresponding section (see 3.1.7 Time Channel).

Resolution: Accepted

Added link to <inkSource>

Email Trail:

Issue 122

From Grégory Pakosz, Vision Objects (2006-12-20):

The appearance of a <traceFormat> element in an ink markup file ...
I would have used "in an InkML file" (see 3.1.9 Specifying Trace Formats).

Resolution: Accepted

Changed "ink markup file" to "InkML file"

Email Trail:

Issue 124

From Grégory Pakosz, Vision Objects (2006-12-20):

All traces must begin with an explicit value, not with a first or second difference. This is true of continuation traces as well. This allows the location and velocity state information to be discarded at the end of each trace, simplifying parser design.
I suggest: "This is true for continuation traces" (see 3.2.1 <trace> element contents).

Resolution: Accepted

Added "This is true for continuation traces"

Email Trail:

Issue 125

From Grégory Pakosz, Vision Objects (2006-12-20):

There is a 3.2.1 <trace> element section but no 3.2.2 section.

Resolution: Accepted

Added section number

Email Trail:

Issue 127

From Grégory Pakosz, Vision Objects (2006-12-20):

Although the use of the <context> element and attributes is strongly encouraged, default interpretations are provided so that they are not required in an ink markup file if all trace data is recorded in the same virtual coordinate system, and its relationship to digitizer coordinates is either not needed or unknown.
"ink markup file" or "InkML" file ? Maybe it's a good idea to chose one and stick to it (see 4.1 The <context> element) ?

Resolution: Accepted

Changed "ink markup file" to "InkML file"

Email Trail:

Issue 129

From Grégory Pakosz, Vision Objects (2006-12-20):

For the sake of consistency, the <srcProperty> element could have been named <sourceProperty>. In fact, it is the only markup that has an abbreviated name (seen 4.2.5 <srcProperty> element).

Resolution: Accepted

The <srcProperty> element will be renamed to <sourceProperty>

Email Trail:

Issue 130

From Grégory Pakosz, Vision Objects (2006-12-20):

The <channelProperties> element is meant for describing properties of specific channels reported by the ink source. Properties such as range and resolution may be specified using corresponding elements. For more esoteric properties (from a lay user's standpoint) the generic channelProperty element may be used.
I would replace "channelProperty" by "[ http://www.w3.org/TR/2006/WD-InkML-20061023/# channelProperty <channelProperty]>" (along with the link) (see 4.2.6 channelProperties element ).

Resolution: Accepted

Changed "channelProperty" to <channelProperty> with a link to channelPropertyElement.

Email Trail:

Issue 131

From Grégory Pakosz, Vision Objects (2006-12-20):

I would replace

name = xsd:string
Name of property of device or ink source.
Required: yes

by

name = xsd:string
The name of the property of device or ink source.
Required: yes

(see 4.2.7 channelProperty element attributes)

Resolution: Accepted

Rephrase per recommendation in comment

Email Trail:

Issue 132

From Grégory Pakosz, Vision Objects (2006-12-20):

There is a 4.3.1 <brush> element section but no 4.3.2 section.

Resolution: Accepted

Added section number

Email Trail:

Issue 133

From Grégory Pakosz, Vision Objects (2006-12-20):

There is a 4.4.1 <timestamp> element section but no 4.3.2 section.

Resolution: Accepted

Added section number

Email Trail:

Issue 136

From Grégory Pakosz, Vision Objects (2006-12-20):

The definitions within a <definitions> block can be referenced by other elements using the appropriate syntax. Content within a <definitions> has no impact on the interpretation of traces, unless referenced from outside the <definitions>. In order to allow them to be referenced, elements within a <definitions> block must include an id; attribute.
Maybe it should be: "Content within a <definitions> block has no impact on the interpretation of traces, unless referenced from outside the <definitions> block". Also, is the semicolon required? (see 6.2.1 definitions element)

Resolution: Accepted

Rephrase per recommendation in comment

Email Trail:

Issue 138

From Grégory Pakosz, Vision Objects (2006-12-20):

[ http://www.w3.org/TR/2006/WD-InkML-20061023/#streamsAndArchives 7 Streams and Archives] rename to "7 Archives and Streams" to match the content of 7.1 and 7.2 sections.

Resolution: Accepted

Rephrase per recommendation in comment.

Comment: Muthu, 03/30/07

On doing this, we have to modify the second paragraph in section 7 where there is a reference to ‘former’ and ‘later’ that refer to Streams and Archives.

Email Trail:

Issue 177

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

2.1 <ink> element -> http://www.w3.org/TR/2010/WD-InkML-20100527/#inkElement
For all but the documentID you give the require and default information.

Resolution: Accepted

The required/default was at the *end* of section 2.1. Move it up with the attribute to match all the other attributes in the spec.

Email Trail:

Issue 178

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

( definitions | context | trace | traceGroup | traceView | annotation | annotationXML )*'
this should be
'trace ( definitions | context | trace | traceGroup | traceView | annotation | annotationXML )*'
So that there MUST be one trace Element.

Resolution: Accepted

Agreed: at least a single <trace> is required. Update the XSD as well.

Email Trail:

Issue 193

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

'Intermittent channels may be encoded with the wildcard character "?".' and'All regular channels must be reported, if only with the explicit wildcard "?".'Because of the first line i cite i think the second is not right. The only wildcard allowed for regular channels is the *.

Resolution: Accepted

Agreed. Changed the wildcard from '?' to '*'.

Email Trail:

2.3 Requests for Change to Existing Features

Issue 14

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

A bare anyURI is inadequate as inkml:ink.documentID

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023/#inkElement

You have given no interoperable definition of what kinds of assertions constitute "application intent" and content formats should define what semantics they denote independent of the processors.

So the bounds on when two files can bear the same URI as this
attribute are undefined.

Just don't let yourselves get caught in the rathole around URIs as to
what sort of repeatability constitutes an identity to which such a
symbol can be attached.

Instead, use Dublin Core to identify the contents if there is the
intent for the contents to be a published entity for which it makes
sense to compare identity codes.

In other words, you may use dc:identifier for this symbol but you
should only do that in the context of a dc:creator and a dc:date, for
example.

Comment: Needs to understand the complexity in naming the document that cited by the commenter.
ACTION ITEM: To check other WG for any best practices followed for this.

Resolution: Rejected

If application requires particular attribution using Dublin Core, they may put DC XML in an AnnotationXML block.

Email Trail:

Issue 20

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Be more explicit about binding reported data to intermittent channels

<quote
cite=http://www.w3.org/TR/2006/WD-InkML-20061023/#trace>

For each point in the trace, regular channel values are reported
first in the order given by the <traceFormat>. If any intermittent
values are reported for the point, they are given next, in the order
they are specified in the <traceFormat>. Unreported intermittent
channels are interpreted as though they were given by the wildcard
"*".
</quote>

This is not an algorithm. There is only one way to interpret it as an
algorithm, but that takes a friendly reading.

The problem is that if some intermittent channels produce no data at a given trace time, they can be omitted from of the reported data
without benefit of placeholders or wild cards and the resulting
reported data will still be *in the order given by <traceFormat>*. So
the specification language is too loose to enforce the behavior
that you seek.

You should ensure by the specification language that any channels
declared in the traceFormat before channels contributing non-* values are reported, even if only with wild cards. The language you have given does not ensure that.

Say something like:

The sequence of reported channels is a head for the sequence of
declared channels, the sequence given in the applicable <traceFormat>.

All Channels declared after the last reported channel are treated
as though a '*' were reported. All channels declared before the
last reported channel must also be reported, if only with explicit wild cards.

Resolution: Accepted

• Changed the Grammar in section 3.2.1 to include value for 1) regular channel and 2) intermittent channel.
• The ‘quoted’ documentation has been be revised to the suggestion given by the commenter.

Email Trail:

Issue 21

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Disallow all qualifiers in intermittent channels

<quote
cite="http://www.w3.org/TR/2006/WD-InkML-20061023/#trace">

Intermittent channels are always encoded explicitly, i.e. the
qualifiers ' and " are not allowed.

</quote>

.. and there's no point in using the qualifier, either, as it is implied.

So just don't allow qualifiers in intermittent channels, period. Saves one representation ambiguity for the interpreting application to have to code for.

PS: editorial: use angle brackets to set off quotes where you would have used quotes to make it clear that you are referencing the character as a token. In other words,

Intermittent channels are always encoded explicitly, i.e. the
qualifiers < '> and <"> are not allowed.

.. but you're not going to need to call them out individually, here, once you fix it.

Resolution: Accepted

This issue is related to the previous issue. Only the grammar for the ‘regular’ channel will have the qualifiers.

Email Trail:

Issue 28

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Pen rotation axis has undefined origin

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023

Your solid geometry was doing fine in defining the pen attitude coordinates
until you came to pen rotation.

<quote
cite="">
Figure 3b shows the Rotation of the pen along its longitudinal axis.
</quote>

There needs to be a definition of what the orientation of the pen is
when this coordinate is zero; the origin of the angular measure that
gets reported.

One possible definition is as follows:

The departure of a reference mark or meridian on the pen barrel from the nominal 'up' direction which may be constructed by a ray
perpendicular to the pen barrel (somewhere not at the tip) and
intersecting a pure-Z ray arising from the tip. This angle is
measured in a clockwise direction when viewing the pen barrel from
tail to tip, in degrees.

This definition would relate well to the force distribution across
the two sides of a fountain pen nib.

A different way to identify the nominal 'up' direction would be the
plane passing through the pen barrel and a pure-Y ray passing through the tip. Here the 'up' direction is a direction that has negative correlation with the Y axis, which normally flows down.

This definition would relate well to the use of an x-acto art knife,
indicating the user's intent as to whether the next bit of the trace
should be increasing or decreasing in X coordinate.

Each of these example definitions is just a quick blurt; you can say
it more simply but you have to say something more than you have said.

Resolution: Accepted

Changed the definition for the rotation of pen to “The departure of a reference mark or meridian on the pen barrel from the nominal 'up' direction which may be constructed by a ray perpendicular to the pen barrel (somewhere not at the tip) and intersecting a pure-Z ray arising from the surface of the pen passing through the tip. This angle is measured in a clockwise direction when viewing the pen barrel from tail to tip, in degrees.”

Email Trail:

Issue 46

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Type technicalities with timing attributes on <trace>

<quote
cite= http://www.w3.org/TR/2006/WD-InkML-20061023/#trace >

duration = xsd:decimal
The duration of this trace, in milliseconds.
Required: no, Default: unknown

timeOffset = xsd:decimal
The relative timestamp or time-of-day for the start of this trace, in
milliseconds.
Required: no, Default: unknown
</quote>

‘undefined’ is not a legal value of xsd:decimal

You need to roll this out in different prose. When the attribute
is not present, no information is given as to the time that this
ink appeared. ‘Default’ has a slightly different semantic than
this, If there is a default, it is a legal value that is true even
when stated.

Suggestion:

For @duration, let the default be zero. (data valid at one time)

For @timeOffset, say Default: none.

Resolution: Accepted

Changed the default value of @duration and @timeOffset from Unknown to None.

Email Trail:

Issue 80

From Al Gilman, WAI Protocols and Formats WG (2006-12-20):

Inspecting the shared canvas

This is not a change suggestion for the InkML specification _per se_, but rather raising a concern that we have in accessibility that it
would seem you will also have to worry about to make Ink-using
applications consistently usable in their look and feel so as to be
accepted by users. To co-exist with other sources in a shared canvas, you need to know what they are doing in all the dimensions of display phenomena that you enter yourself.

InkML Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023

Issue Reference:
Find "actual presentation properties" in (Member confidential link)
http://lists.w3.org/Archives/Member/w3c-wai-pf/2006OctDec/0144.html

Client-side scripts that attempt to meet accessibility guidelines by assuring color contrast between the effects they control and the surrounding background color of the canvas have run into problems when:

>The CSS cascade resolves to 'clear' but there is a background color or image that shows through -- layered by the operating system outside the control of the CSS-driven rendering engine.

Applications that share multi-user ink traces with platform imagery
on a common canvas will encounter similar problems. The application will be color-coding the traces; and it will need to be concerned to allocate colors to the traces that will not only distinguish one trace from another but likewise be perceivable against the background arriving on the canvas from other sources.

http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast

We can't expect all the other content painting on the canvas to get
transcoded into InkML but we should expect full information in some
common canvas coordinates. In addition, one should be able to inspect starting from the underlying object model which is the origin of other-source canvas effects, as in HTML+CSS.

There are similar problems with locations on the canvas. One common function of ink traces in whiteboard usage cases is to hook something in the background scene to attach an annotation. For this to work reliably, the final ink placement of the rendered text or other DOM objects must be knowable, reliably and accurately.

>Brad A. Myers, Choon Hong Peck, Jeffrey Nichols, Dave Kong, and Robert Miller. "Interacting At a Distance Using Semantic Snarfing," In Proceedings of Ubicomp 2001. Sept 30-Oct 2, Atlanta, Georgia. pp. 305-314. http://www.cs.cmu.edu/~pebbles/papers/pebblessnarfubicomp.pdf

This is not anything that impacts the definition of the Ink format, but it is something that impacts the success of Ink-using applications.

Please join with the WAI and the Working Groups working on the DOM and Delivery Context Interfaces to secure and ensure full and accurate access to this information about content rendered to the canvas.

Comment: We prefer to leave the 'anchoring' idea for the application developer to take care. But we might consider the 'rendering' aspects. We will go through this issue description in detail to decide on what the spec may need to support.

Resolution: Accepted

Added clarifying statement to this effect: Its legitamite for a host app to have an accessbilty mode or alternate rendering mode where the explict color values in the InkML are reinterpretted to other colors for better accessiblity or suitablity of the rendering device. Color to black and white for example.

Added the clarification to section 3.1.5 Color Channels.

Email Trail:

Issue 87

From David Carlisle, Math WG (2006-12-14):

Schema for MathML subset

A subset of mathml is given by listing the allowed elements but no
schema is given for the restricted grammar. There should be, especially as this isn't an entirely trivial restriction of the mathml schema to the specified elements as there are extra conditions, eg <list> restricted to top level.

Resolution: Accepted

The subset of MathML to be used in <mapping> definition has been explicitly stated and there is now an inkml-mathml2-subset.xsd included by inkml.xsd that explicitly defines the subset of MathML supported by InkML.

Email Trail:

Issue 147

From David Carlisle, Math WG (2006-12-14):

Request for a DTD/Schema/RelaxNG specification

http://lists.w3.org/Archives/Public/www-multimodal/2006Dec/0001.html

It was rather surprising to see no formal specification of the InkML
markup (No DTD, XSD or Relax NG schema). We had expected that mainly to be commenting on how (a subset of) mathml was integrated into the schema, and whether any additional hooks in the mathml schema would help that integration. This plan fell at the first hurdle as there appears to be only a prose text description of the grammar.

Resolution: Accepted

Added an Appendix containing a link to the InkML XML Schema. The inkml.xsd includes an inkml-mathml2-subset.xsd that defines the MathML2 subset supported by InkML.

Email Trail:

Issue 152

From Dominique Hazael-Massieux <dom@w3.org> (2010-06-16):

* 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.

Email Trail:

Issue 12

From Grégory Pakosz, Vision Objects (2006-12-20):

The media type of InkML document is application/inkml+xml. See the Media Type definition for details. This media type is expected to be registered with IETF.

>>> Is the media type registered yet or does the sentence come from the original version of the document?

Resolution: Accepted

Appendix B has been updated per the agreements made by the subgroup during the July 15, 2008 meeting: http://lists.w3.org/Archives/Member/w3c-mmi-wg/2008Jul/0041.html

Email Trail:

Issue 15

From Grégory Pakosz, Vision Objects (2006-12-20):

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023/#inkElement
Why using a specific "documentID" attribute? Why not using xml:id?

Resolution: Rejected

Although I agree that xml:id may have been a better, more consistent choice, it’s too late now – implementations exist that implement documentId.

Email Trail:

Issue 47

From Grégory Pakosz, Vision Objects (2006-12-20):

The type attribute of a <trace> indicates the pen contact state (either "penUp" or "penDown") during its recording. A value of "indeterminate" is used if the contact-state is neither pen-up nor pen-down, and may be either unknown or variable within the trace. For example, a signature may be captured as a single indeterminate trace containing both the actual writing and the trajectory of the pen between strokes.

The "type" attribute overlaps the definition of the reserved S channel for tip switch state (touching / not touching the writing surface).
Now that the "type" attribute exists, a <trace> element can have its "type" attribute set to "penDown" while the actual trace data contains information about the tip being up or vice-versa! In such a case, I guess that it is up to the application to decide how to interpret the InkML file which by definition breaks interoperability.

The default trace format could have defined an intermittent boolean S channel that defaults to true == pen down:
The reader does not know the answer until reading the 4.3.1 <brush> element section:
Same question goes for a continuation trace that has the "continuation" attribute set to "begin" while the "priorRef" attribute is defined
It really seems that the <trace> element model is not robust enough in the sense that it permits undefined or application specific behavior.

Resolution: Accepted

We will add the clarification to the spec that the S Channel overrides the pen type value (the type attribute on the <trace> element)

Email Trail:

Issue 48

From Grégory Pakosz, Vision Objects (2006-12-20):

Also, the specification should give precise use cases for continuation traces. In archival mode, splitting a whole trace into continuation traces has no use (and it would not be difficult to produce correct markup, see above). But continuations traces are needed in the case of collaborating applications (streaming mode), e.g user 1 is writing on device A and the digital ink has to be dynamically replicated on the screen (device of user 2.

Streaming mode side note:

<trace id="t1" type="penDown" continuation="begin" ...>...</trace>
<trace id="t2" continuation="middle" priorRef="#t1" ...>...</trace>
<trace id="t3" continuation="end" priorRef="#t2" ...>...</trace>

This would be the typical markup produced when being in streaming mode. In the use case described above, that is user 2 seeing what user 1 is writing, if you want a quick and smooth ink rendering on user 2's screen, then the amount of actual trace data will definitely be VERY SMALL compared to the amount of markup being produced, even when additional attributes are not taken into account. Also, I am not very familiar with XML streaming in general but I imagine that something like SOAP adds its own overhead.

<trace id = "toBeSplit"> 1125 18432,'10 '22,'5 '7,'8 '23','10 '8 F,'5 '7,'2 '11,'7 '5 T,'10 '7 </trace>

is likely to be split into

<trace id="t1" type="penDown" continuation="begin">1125 18432</trace>
<trace id="t2" continuation="middle" priorRef="#t1">'10 '22</trace>
<trace id="t3" continuation="end" priorRef="#t2">'5 '7</trace>
<trace id="t4" continuation="end" priorRef="#t3">'8 '23</trace>
<trace id="t5" continuation="end" priorRef="#t4">'10 '8 F</trace>
<trace id="t6" continuation="end" priorRef="#t5">'5 '7</trace>
<trace id="t7" continuation="end" priorRef="#t6">'2 '11</trace>
<trace id="t8" continuation="end" priorRef="#t7">'7 '5 T</trace>
<trace id="t9" continuation="end" priorRef="#t8">'10 '7</trace>

which has little chance of being very Bluetooth friendly

Resolution: Rejected

The issue seems to be an implementation issue. Yes, the application in the above example add lot of InkML markup data overhead on wire and demand high processing power; may the user find a different solution to do solve the problem. We may not require to modify the specification for solving this issue.

Email Trail:

Issue 49

From Grégory Pakosz, Vision Objects (2006-12-20):

If a continuation attribute is present, it indicates that the current trace is a continuation trace, i.e. its points are a temporally contiguous continuation of (and thus should be connected to) another trace element. The possible values of the attribute are:
begin, end and middle.

As far as I can recall the discussions that took place during the face to face meeting in NYC, "begin" "end" and "middle" are to be used when wanting to render the traces with the help of splines: obviously you computations differ depending on it is the beginning of the trace, the middle or the end.

In fact it is all biased by the fact that InkML is supposed to be parsed by a standard DOM or SAX XML parser. With such a predicate, you cannot avoid having to cut traces into smaller pieces of valid markup. As a consequence, InkML is somehow forced to introduce the concept of data packets at the OSI application layer level, while existing network protocols like TCP/IP already take care of it.

With a custom InkML parser one could imagine doing:
"<trace>1125 18432," message is sent by user 1 and received by user 2.
-- this is the beginning of the trace because there is a <trace> markup.
"'10 '22, '5 '7," message is sent by user 1 and received by user 2.
-- this is the middle of the trace because only coordinates are sent.
...
"'10 '7</trace>" message is sent by user 1 and received by user 2.
-- this is the end of the trace because there is a </trace> markup.

Resolution: Rejected

• The issue seems to an implementation issue. Yes, the application in above example add lot of InkML markup data overhead on wire and demand high processing power; may the user find a different solution to do the same.
• The spec may attempt to reduce the amount of mark up generation in this case. One idea is to replace the ‘continution’ attribute with a Boolean attribute to indicate the ‘end’ fragment. So all the ‘trace’ elements except the last one need not to have the ‘continution’ attribute.
• The implementation specific discussions can be addressed in ‘tutorials’ like documents.

Email Trail:

Issue 50

From Grégory Pakosz, Vision Objects (2006-12-20):

Note: the trace syntax defined here makes the InkML file sizes (as well as the XML DOM trees) smaller while keeping the benefits of XML. However some applications, for instance those concerned with transmitting InkML documents across the Web, might require even smaller file sizes. It is thus recommended (but not required) that InkML implementations support the gzip standard compression scheme (see [RFC1952]).

I suppose you recommend supporting whole gzip compressed ".inkml.gz" files. Some Anoto pen manufacturer decided to use an XML based file format where the ink traces markup is compressed using a zip compression scheme then encoded in Base64 before being re-injected into the XML document: you reduce the amount of data by compressing but you increase it afterwards because of the Base64 encoding ... (see http://www.w3.org/TR/2006/WD-InkML-20061023/#traceContents 3.2.1 <trace> element contents]).

Comment: The recommendation of the spec is a valid idea but may not be optimized. We need further investigation by looking at how does this requirement is solved in general and if there is an optimum technique for it. We may look in to how SOAP XML request in Web Services handled.

Resolution: Accepted

Removed the "Note:" paragraph that suggest the use of 'gzip' from the specification.
Added the resolution given in the message http://lists.w3.org/Archives/Member/w3c-mmi-wg/2007Dec/0021.html, as an appendix of the specification document.

Email Trail:

Issue 55

From Grégory Pakosz, Vision Objects (2006-12-20):

The <traceView> element is used to group traces by reference from the current document or other documents.
If a traceDataRef attribute is given, then a to and/or from attribute may be given. Together, traceDataRef, from and to refer to another element and select part of it. An traceDataRef attribute may refer to a <trace>, a <traceGroup> or another <traceView>.

I do not really understand why the <traceView> element is itself a group. Why can't a <traceView> element be part of a <traceGroup>???
Why isn't a <traceView> just a view instead of being view+group ?

<traceView xml:id="L3">
<traceView traceDataRef="#L1" from="2"/>
<traceView traceDataRef="#L2" from="2" to="4:1:1"/>
</traceView>

Why can't it be:
<traceGroup xml:id="L3">
<traceView traceDataRef="#L1" from="2"/>
<traceView traceDataRef="#L2" from="2" to="4:1:1"/>
</traceGroup>

(see 3.3.2 <traceView> element contents and 3.3.2 <traceView> element examples).

Resolution: Accepted

Yes, it would be have been a possible design to allow traceGroups to contain traceView's and thus require traceView's only as leaf elements. We could even have modified trace to have a traceDataRef and do away with traceView altogether. This would make handling traces and traceGroups more complicated however.

Email Trail:

Issue 62

From Grégory Pakosz, Vision Objects (2006-12-20):

Each constituent part of a context may be provided either by a referencing attribute or as a child element, but not both. Thus it is possible to have either a traceFormatRef attribute or a <traceFormat> child element, but not both.

Can an XML schema enforce this (see 4.1 The context element)?

Proposal 1: May allow defining both the referencing attribute as well as child element. Then the ambiguity can be resolved by a guideline that the child element value will override the value derived from the referencing attribute. So the existence of both is equivalent to having child element alone.

Resolution:
Stephen: Normative English text that says "which one should be used" needed.

Proposal 2: Remove the referencing attributes and always allow only child elements.
The sample usages are given below,

Example 1: To refer to the already defined brush.
At present, it is achieved by,
<context id="ctx2" contextRef="#ctx1" brushRef="#brush1"/>.
Then it will be changed to, <context id="ctx2" contextRef="#ctx1">
<brush brushRef="#brush1"/>
</context>.

Example 2: To define a new brush for the context.
<context id="ctx2" contextRef="#ctx1">
<brush id="brush2"/>
</context>

Resolution: Accepted

Done. Normative clarifying language added. We continue to allow, e.g., both a brushRef and a brush child of context, but say which takes priority.

Email Trail:

Issue 63

From Grégory Pakosz, Vision Objects (2006-12-20):

The <inkSource> block will often be specified by reference to a separate xml document, either local or at some remote URI. Ideally, <inkSource> blocks for common devices will become publicly available.
Do you plan to setup a repository on the W3C's website (see 4.2.1 <inkSource> element)?

Resolution: Accepted

The statement will be removed, because W3C (WG) do not have a plan to set up such a repository as of now.

Email Trail:

Issue 64

From Grégory Pakosz, Vision Objects (2006-12-20):

The <sampleRate> element captures the rate at which ink samples are reported by the ink source. Many devices report at a uniform rate; other devices may skip duplicate points or report samples only when there is a change in direction. This is indicated using the uniform attribute, which must be designated "false" (non-uniform) if any pen-down points are skipped or if the sampling is irregular.
uniform = xsd:boolean
Sampling uniformity: Is the sample rate consistent, with no dropped points?
Required: no, Default: unknown
value = xsd:decimal
The basic sample rate in samples/second.
Required: yes
So, when the ink source has an irregular sampling rate, the sampling rate "value" is still required BUT the "uniform" attribute has to be set to false? Isn't this contradictory? What is the purpose of giving a sample rate value when you know in advance that sampling is irregular?

Also, when you write "<sampleRate value="200"/>" then the "uniform" attribute is by default set to "unknown", but it IS known to be uniform because a value is given.

Comment: Greg, 12/20/06
As a consequence, I suggest dropping the "uniform" attribute and have a special sampleRate value in case the source is non uniform, something like negative (<= 0) value means unknown.

In both cases, that is in the case of the actual specification or in the case of my new proposal, I am really wondering whether or not an InkML schema is capable of handling it (see 4.2.2 <sampleRate> element).
Comment: Muthu, 04/11/07
The <inkSource> element is defined to have “zeroOrOne” <sampleRate> child element. So We should use <sampleRate> element only when there is a uniform sampling rate and skip it when the sampleRate is not uniform. So there is no specific attribute is required to indicate the uniform property.
Ofcourse, It is easy to enforce this solution in Schema definition.

Resolution: Accepted

Time channel should be used to get time information when Sampling Rate is non Uniform. When the Sampling Rate is Not Uniform, the value attribute of SampleRate element should be maximum sampling rate. The default value of the ‘uniform’ attribute should be true.

Email Trail:

Issue 65

From Grégory Pakosz, Vision Objects (2006-12-20):

The <latency> element captures the basic device latency that applies to all channels, in milliseconds, from physical action to the API time stamp. This is specified at the device level, since all channels often are subject to a common processing and communications latency.


Does this <latency> element come from the ancient times when the first specification draft was crafted up or is there any practical use of this element?
And what if it's not the case? What if latency differs from one channel to another? If the knowing of the latency is of any importance, then you would end up having defined useless markup (see 4.2.3 <latency> element).

As a consequence, why not bring latency information down to the <channelProperty> element (see 4.2.7 channelProperty element)?

Resolution: Rejected

No Change.
Note: Channel Property should appear as child to channel. It saves space, less overhead on the parser/interpreter in terms of associating property to the channel.

Email Trail:

Issue 66

From Grégory Pakosz, Vision Objects (2006-12-20):

size = xsd:string
The active area, described using an international paper size standard such as ISO216.
Required: no, Default: unknown

This is a good example of a typical drawback of InkML. You can refer to an international paper size standard such as ISO216 if it pleases you, however do not expect this information to be accurately used by any other application than yours. If there is nothing to enforce or to define the meaning of the attribute with precision, then why not drop it in favor of a custom <annotation> element?

In the end, I think that such design choices break interoperability (see 4.2.4 <activeArea> element).

Resolution: Accepted

Change in Spec:
The active area, described using an international ISO paper sizes standard such as ISO216
Width and Height attributes should be made mandatory.
Units attribute will be in one of the standard units.
Note: Channel Property should appear as child to channel. It saves space, less overhead on the parser/interpreter in terms of associating property to the channel.

Email Trail:

Issue 74

From Grégory Pakosz, Vision Objects (2006-12-20):

At most one of the attributes time, timestampRef or timeString may be given. The time thus given, plus the value of the attribute timeOffset, gives the time value of the timestamp.
Again, can this be enforced by a schema (see 4.4.1 <timestamp> element contents)?

Comment: Muthu, 04/11/07
We may consider the following change in the structure,
1. Remove the attributes time and timeString. Let the value given in the content with the type, <xs:union memberTypes="xsd:time xsd:dateTime"/>. So the content can be either of time or of type dateTime String.
2. Resolving Ambiguity: When both timeStampRef attribute and content or used, the content value gets precedence over the timeStampRef attribute. In other words, the timeStampRef attribute should be ignored.

Resolution: Accepted

Specified priority order on time, timeString and timestampRef.

Email Trail:

Issue 78

From Grégory Pakosz, Vision Objects (2006-12-20):

For certain classes of mappings, the inverse mapping may be determined automatically. These are mappings of type "identity", "affine" (for matrices of full rank), "lookup" (univariate, with linear interpolation), and "product" mappings of these. In this case, it is possible to specify that an inverse should be determined automatically by giving only the forward transform and specifying a value of true for the invertible attribute.
When the inverse transform cannot be computed numerically, the inverse <mapping> has to be provided. In such a case, does the "invertible" attribute need to be set to "true" (see 5.2 element contents)?

<canvasTransform>
<mapping type="unknown"/>
<mapping mappingRef="#map001"/>
</canvasTransform>

The example provided let the user think this is not the case. However, what if two <mappings> and "invertible = true" are specified?

Comment: Muthu, 04/11/07.
The following changes may be considered,
Drop the attribute invertible. Always force to use two <mapping> child element to provide the forward and inverse transform.

To indicate a mapping is invertible of another mapping: Introduce “invertibleRef” attribute which should be optional in mapping element. This attribute when used with href attribute to point to the mapping from which this mapping can be numerically invertible.

Ambiguity: When both the mappingRef and Child elements to define the mapping are used, the child elements which define the mapping gets precedence and the mappingref attribute is ignored.

Resolution: Accepted

If both mappings are provided, then ignore the ‘invertible’ attribute. Added this description to the spec.

Email Trail:

Issue 89

From Grégory Pakosz, Vision Objects (2006-12-20):

Unknown Mapping Type
InkML supports several types of mappings: unknown, identity, lookup table, affine, formula (specified using a subset of MathML) and cross product. The mapping type is indicated by the type attribute of a <mapping> element.
What if something other than "unknown", "identity", "lookup", "affine", "mathml" or "product" is used? Should it be interpreted as "unknown" or as an application specific mapping type? In such a case, what about interoperability between applications (see 6.1 Mappings)?

Resolution: Rejected

We believe that all types of mapping can be explained using the available type of mappings especially the MathML mapping type support wide variety of mapping definitions. So there will not be a case to provide application specific mapping definition. The application specific mapping type definition is not supported by InkML standard.

As per the spec, it is useful in <canvasTransform> definition to give only inverse transform by setting the forward transform mapping type as "unknown".

There is a proposal to drop the generic <mapping> element and create Specific element for each possible mapping type, it is discussed in Section 6.1.2: <bind> element Issue No: 1 which aims to solve the invalid combinations of attributes in the <bind> child element.

Email Trail:

Issue 91

From Grégory Pakosz, Vision Objects (2006-12-20):

source = xsd:string
Specifies source data values and/or channel to be considered in the mapping.
Required: no, Default: none

target = xsd:string Specifies target data values and/or channel to be considered in the mapping.
Required: no, Default: none
column = xsd:string
Specifies the assigned column within a lookup table either for source or target channels.
Required: for lookup table bindings, Default: none

variable = xsd:string
Specifies the variable within a formula that represents the current source data/channel.
Required: for mathml bindings, Default: none

This truly offers pretty much room for invalid combinations (see 6.1.2 <bind> element attributes).

Comment: Muthu, 04/11/07.
We may consider the following change,

Drop the <mapping> element and create different Mapping element for each possible mapping type with <bind> child element that have only the relevant attribute list.


Example: For mapping type = lookup, We can create a <tableMapping> element as given below,
<tableMapping id=”mapping1”>
<bind target="X" column="1"/>
<table> </table>
</tableMapping>

All the Mapping element can have “href” attribute which play the role of mappingRef attribute in the <mapping>.

Comment:
Stephen will evaluate the above proposal.

Resolution: Accepted

This is tracked by ISSUE-69 provided by Muthu.

We update the column attribute data type to be integer, and explicity described the legal combinations of attributes. We also corrected errors in the MathML example (removed type="setvar").

Email Trail:

Issue 95

From Grégory Pakosz, Vision Objects (2006-12-20):

The definitions within a <definitions> block can be referenced by other elements using the appropriate syntax. Content within a <definitions> has no impact on the interpretation of traces, unless referenced from outside the <definitions>. In order to allow them to be referenced, elements within a <definitions> block must include an id; attribute.
What happens when references are made to elements outside <definitions> blocks?

Resolution: Rejected

Reference to elements defined outside <definitions> is allowed.
The diffrence between the elements defined "inside" <definitions> and "outside" <definitions> is that the former does not represent ink data whereas the later lively represents ink data.
The commmon thing about them is that both are available for reference by other elements.

Email Trail:

Issue 97

From Grégory Pakosz, Vision Objects (2006-12-20):

Another use of <definitions> is to define digital ink traces for later reference. These may be given by <trace>, <traceGroup> or <traceView>, and may be referenced from other elements by the traceDataRef attribute. This is useful in archival applications.
Same question, is it mandatory to put ink traces inside <definitions> elements when you want to reference them later on?

Resolution: Rejected

It is not mandatory.

Email Trail:

Issue 100

From Grégory Pakosz, Vision Objects (2006-12-20):

Interoperability issue because of <annotation> and <annotationXML>

InkML provides generic ways of assigning metadata or semantics to ink via two elements <annotation> and <annotationXML>, modeled after the corresponding elements in MathML. However since annotations are typically application-specific, InkML does not attempt to prescribe the contents of these elements.
Which is why InkML itself is unlikely to be useful as an exchange format, and lacks interoperability.

Resolution: Accepted

It is natural that annotations are not interoperable. As a design principal, we want to support them as placeholder for the user defined information such as the recognition results and user defined brush properties etc.
We can document this fact of them being harmful for interoperability in <annotation> and <annotationXML> elements sections.

Added sentence to 6.3 Annotations: "Since the contents of <annotation> or <annotationXML> elements are application defined, implementors should use them with care and remain aware that other implemnetaions may ignore them or fail to round-trip unrecognized annotations."

Email Trail:

Issue 101

From Grégory Pakosz, Vision Objects (2006-12-20):

Semantic tagging of traces
The <annotation> element provides a mechanism for inserting simple textual descriptions in the ink markup. This may be use for multiple purposes. For instance, the text contained in the <annotation> may include additional information provided by the user generating InkML, and may be displayed by an InkML consumer rendering a graphical representation of traces. Or it may be used for the indication of metadata such as the writer, the writing instrument. Another important potential application is the semantic tagging of traces.
Semantic tagging of traces is important. Maybe InkML should address it more thoroughly (see 6.3 <annotation> element).

Resolution: Accepted

The explanations given as part of the resolution of the above issue (Section 6.3, #100) will address this.

Email Trail:

Issue 102

From Grégory Pakosz, Vision Objects (2006-12-20):

Suggestions on Semantic tagging of traces
For semantic tagging, one of the common types of <annotation> is "contentCategory", which describes at a basic level the category of content that the traces represent; e.g., "Text/English", "Drawing", "Math", "Music". Such categories are useful for general data identification purposes, and may be essential for selecting data to train handwriting recognizers in different problem domains.

Although largely application-defined, a number of likely, common categories are suggested below.
1. Text/<language>[/<script>][/<sub-category>] (e.g., Text/jpn/Kanji, Text/en/SSN)
1. Drawing[/<sub-category>] (e.g., Drawing/Sketch, Drawing/Diagram)
1. Math
1. Music
1. Chemistry[<sub-category>]

The language specification may be made using any of the language identifiers specified in ISO 639, using 2-letter codes, 3-letter codes, or country names. Some text may also require a script specification (such as Kanji, Katakana, or Hiragana) in addition to the language.

For some applications it may be useful to provide additional sub-categories defining the type of the data. For example, some suggested sub-categories for Text include:
1. SSN (Social Security Number)
1. Phone
1. Date
1. Time
1. Currency
1. URL

Suggested possible sub-categories for Drawing are:
1. Sketch (Not suitable for geometric clean-up)
1. Diagram (Suitable for geometric clean-up)
InkML suggests ways of tagging ink traces. Unfortunately, those are only suggestions. Handwriting recognition is a primary treatment performed on handwritten digital data, and annotation suggestions are not enough to enable handwriting recognition aware applications to interoperate with each other.

Resolution: Rejected

The comment is interesting and complex. As the <annotation> element is left for application dependent definitions, an elaborate description of 'contentCategory' as part of the standards specification is not favored.

Email Trail:

Issue 104

From Grégory Pakosz, Vision Objects (2006-12-20):

This element allows ink to be annotated with general XML objects. These may be given either as the content of this element or may be referred to by a href attribute, but not both.
Again, practical to use, but may be difficult to enforce.

Resolution: Accepted

The issue is addressed by the resolution of the issue #143 in the section, "Spec-wide". The name of the self-referencing attribute 'href' is being under review; we are thinking of giving a more suitable name for it which is also addressed in "Spec-wide", issue #143.

1. Support 'href' attribute that can refer to another element of the same type in all appropriate elements.
Example: context, all the children of context, mapping and annotationXML.

2. When a element have 'href' attribute and children then, the data in children overrides the data inherited from the referred element. It is applicable for leaf elements such as 'brush'.

Interpretation of the data when both 'href' and child elements are used : The value of the element is inherited from the element value through 'href' attribute and the child element definition would override the inherited value to get the final value for the child element of the element. This behavior is commonly known as "inheritance".

Email Trail:

Issue 105

From Grégory Pakosz, Vision Objects (2006-12-20):

Suggestion on parser implementation for Units
Even units require a dedicated parser, although it should not be that difficult to write one with the help of regular expressions.

Resolution: Accepted

The channels have now been defined with default units.

We defined default value for all units.
For example the default value for 'length' units is 'mm'.

Email Trail:

Issue 27

From Jonathan Chetwynd, SVG WG (2006-11-04):

Orientation vs Tilt

Paolo Pinzuti in a recent private email suggested that Wacom would not be supporting orientation as distinct from tilt.

Reference:
http://www.w3.org/TR/2006/WD-InkML-20061023/#orientation
The third degree of freedom in orientation is generally defined as the rotation of the pen about its axis. This is potentially useful (in combination with tilt) in application such as illustration or calligraphy, and signature verification.

Resolution: Rejected

The 'tilt' value is captured by the ‘orientation channels’ such as OTx and OTy. This fact is not otherwise mentioned explicitly in the specification document.

Email Trail:

Issue 148

From Jonathan Chetwynd, SVG WG (2006-11-04):

Use with SVG

1. How is it intended that InkML be used with SVG?
http://lists.w3.org/Archives/Public/www-multimodal/2006Nov/0001.html

SVG isn't mentioned within the draft, and it would be useful to have
at least one working example ~:" defining one means of relating SVG:animateTransform to InkML:Time Channel?

The working group will be aware that there has been some controversy and indeed confusion over the use of CSS within SVG**.

It is also proving difficult to easily validate mixed XML namespaces
such as RDF within SVG.

Is the M-MWG in a position to broach these inter-disciplinary
boundaries with signal examples?

Resolution: Accepted

InkML can be annotated with SVG using the <annotationXML> construct.

Email Trail:

Issue 149

From Jonathan Chetwynd, SVG WG (2006-11-04):

Contributions from UA & Wacom

Have there been contributions from User Agent, browser developers or Wacom? Neither appear to be included in the list of authors and editors.

Resolution: Rejected

No, they have not made any contributions.

Email Trail:

2.4 New Feature Requests

Issue 39

From Al Gilman, WAI Protocols and Formats WG (2006-12-18):

Roll-your-own BNF –NOT

If the BNF you are using
http://www.w3.org/TR/2006/WD-InkML-20061023/#trace is a subset of the EBNF used in XML
http://www.w3.org/TR/2000/REC-xml-20001006#sec-notation please say so.

Compare with
http://www.w3.org/TR/SVGMobile12/refs.html

Resolution: Accepted

Changed the spec to explicitly state that the EBNF used in the InkML spec is the subset of EBNF defined by the XML spec.

Email Trail:

Issue 199

From Charles Pritchard <chuck@jumis.com> (2010-06-30):

I'm currently working on an SVG+InkML profile, and having reasonable
success.

Something came up for me:
InkML does suggest that brush properties be left to the implementation:
http://www.w3.org/TR/InkML/#brushElement
"Brushes may be used to convey information... all that matters is that
brushes are distinct so no brush properties are necessary"

It also provides a mechanism to pass metadata about brushes, through the
brushProperty element:
http://www.w3.org/TR/InkML/#brushPropertyElement

brushProperty works quite well in archived mode, for brush metadata.

However, it doesn't seem that it's been examined for Streaming mode.
Within a stream, we want to minimize the number of defined brushes, and will
likely build-upon a brush, changing its color, size, etc.

While the channels definition allows for some measure of this kind of
activity,
it has nothing to offer when it comes to brush property meta data.
....

It seems to me that a stream should be able to re-use and replace the
definitions
construct. This allows inheritance of existing values across boundaries,
and setting
boundaries for garbage collection of obsolete element information.

The following example is intended for streaming mode.

It sets up a brush called "mybrush", with three brushProperty elements.
Later on in the stream, it re-uses that brush, with its brushProperty
elements,
but alters a few of them, changing the value of the first element and
emptying
the value of the third.

By using <definitions> to clear the defined state stack, we're able to allow
streaming implementations to process an unlimited amount of data without
requiring they keep prior definitions in memory; and we allow them to
reference the prior definition set through inheritance.



Example:

<definitions>
<brush xml:id="mybrush">
<brushProperty name="key1" value="val1" />
<brushProperty name="key2" value="val2" />
<brushProperty name="key2" value="val3" />
</brush>
</definitions>
<context brushRef="#mybrush">
<trace> ..... </trace>
<definitions>
<brush xml:id="mybrush" brushRef="#mybrush">
<brushProperty name="key1" value="newValue" />
<brushProperty name="key3" value="" />
</brush>
</definitions>
<context brushRef="#mybrush">
<trace> ..... </trace>

Resolution: Rejected

In section 7.2, "Streaming Application", the spec already says:

The appearance of a <brush>element in the ink markup sets the current brush attributes, leaving all other contextual values the same. Likewise, the appearance of a <traceFormat> element sets the current traceFormat, and the appearance of a <context>element sets the current context. As this would imply, and the examples later illustrate, an anonymous <context> may appear within the stream that overrides all or parts of the current context.

Although there are no examples showing this, this statement says that anonymous <traceFormat> or <brush> elements may also appear within the stream and would also override those parts of the current context (override the traceFormat of the context if an anonymous <traceFormat> appeared, or override the brush of the context if an anonymous <brush> appeared).

The sections for traceFormat (3.1.1) and context (4.1) already support anonymity for streaming because their xml:id attributes are already optional. The section for brush (4.3.1) does not support anonymity because its xml:id attribute is required. We believe that is an oversight on our part and will change it from required to optional in both section 4.3.1 of the spec and in the XML Schema.

I will also update the examples to show samples of streaming XML overriding brushes. For instance:

<brush brushRef="#penA"/>
<trace xml:id="t001">...</trace>
<brush brushRef="#penA">
<brushProperty name="color" value="#FF0000"/>
</brush>
<trace xml:id="t002">...</trace>

In the example above trace "t001" would be render using the attributes of brush "penA". Then the current brush is modified to a copy of "penA" with its color attribute changed to red. Trace "t002" is then rendered using the new current brush which is red.

A streaming application must still store maps of any explicitly named brushes, traceFormats, and contexts. But it would only have to store a single "current" context which contains a "current" brush and a "current" traceFormat. As anonymous brushes, traceFormats, and contexts are encountered in the stream, the implementation writes over the fields within its "current" objects.

The language and example in section 7.2 (Streaming Application) that specifies the use of brushRef="" and canvasRef="" (with empty values) to reference the default brush or default canvas is actually inconsistent with the rest of the spec. The rest of the spec defines reserved URIs for default constructs, e.g. "#DefaultCanvas", etc. We've revised section 7.2 to make it consistent with the rest of the spec. The updated paragraph now reads:

In order to change a contextual value back to its default value, its attribute can be specified with the value "#DefaultCanvas" or "#DefaultBrush". In the following:

<context canvasRef="#canvasA" brushRef="#penA"/>
<trace xml:id="t001">...</trace>
<context canvasRef="#DefaultCanvas" brushRef="#DefaultBrush"/>
<trace xml:id="t002">...</trace>

Trace "t001" is on "canvasA" and has the brush specified by "penA", while trace "t002" is on the default canvas and has the default brush.

Email Trail:

Issue 84

From David Carlisle, Math WG (2006-12-14):

MathML in mappings

A subset of content mathml is "built in" to the mapping element if
used with type="mathml" (or at least I guess that is the intention)

the spec says
type = "identity" | "lookup" | "affine" | "mathml" | "product" |
"unknown"

Contents
(bind* (table | matrix | mathml:math)?) | mapping *

So it appears that identity="mathml" is required for content of
mathml:math and that mathml:math refers to
{http://www.w3.org/1998/Math/MathML}math
but the spec doesn't actually say this (and the schema doesn't exist:-)

Resolution: Accepted

Added an explicit statement to the spec saying "mathml" is declared as the MathML namespace for the MathML schema.

Email Trail:

Issue 99

From David Carlisle, Math WG (2006-12-14):

MathML in annotations

The other use of Mathml is in annotationXML where (apparently) use of arbitrary, unrestricted MathML is allowed. (although as with annotationxml in mathml, a InkML processor needn't understand the annotation)

Perhaps it should (or at least could) be clarified that when "mathml" is given as an example of a possible xml annotation, that it means all of mathml, rather than the mathml restricted subset that is allowed in the mapping element. The reason for highlighting the difference is that while it's easy (or even perhaps obvious) how to say that in English, some care would need to be taken in a schema definition to allow a specific subset of mathml in one element but simultaneously to allow all mathml as part of "any foreign namespace" in annotation XML.

Resolution: Rejected

Not necessary to clarify that MathML can appear in full inside an annotationXML block. Even InkML could appear in annotationXML. The inclusion of an XSD for InkML will help clarify this: the defintion of annotationXML is <xsd:any/>.

Email Trail:

Issue 4

From Grégory Pakosz, Vision Objects (2006-12-20):

"InkML provides means for extension. By virtue of being an XML-based language, users may easily add application-specific information to ink files to suit the needs of the application at hand."
At the cost of losing interoperability.

Comment: Muthu
May need to explicitly specify this fact.

Resolution: Accepted

Rephrased: InkML can include XML from other schemas by using the AnnotationXML construct. Additionall, InkML could be embedded within other XML documents.

Email Trail:

Issue 6

From Grégory Pakosz, Vision Objects (2006-12-20):

Efficiency of Searching for Retrieving the archived handwritten notes
This way of searching handwritten notes is far from being efficient. If the annotation associated with a piece of ink comes from an incorrect handwriting recognition result, you would never recover. Modern digital ink searching rather "tries to recognize what you are looking for" among all your digital handwritten notes. To speed up the search process, the handwriting recognition process is split into parts that can be serialized and used as preprocessing stages for later ink searching. The result of this preprocessing is stored as index files that only need to refer to the actual trace data for search result presentation needs: for instance displaying a dialog box that render an excerpt of the ink. However, trace data is not useful at all for the search process itself.

Resolution: Accepted

Agreed, below is the revised language in section 1.1:

Ink Archiving and Retrieval

A software application may allow users to archive handwritten notes and later retrieve them by a variety of mechanisms. using either the time of creation of the handwritten notes or the tags associated with keywords. The tags are typically text strings created using a handwriting recognition system.

Email Trail:

Issue 11

From Grégory Pakosz, Vision Objects (2006-12-20):

In: http://www.w3.org/TR/2006/WD-InkML-20061023/#OverviewModes

“For ease of implementation, it is recommended that, in archival mode, referenced elements be defined inside a declaration block using the <definitions> element.”

I am sure this remark has some importance otherwise it would not be included in the specification. However at this point of the document, its meaning is unclear to a beginner. A concrete example would help.

Resolution: Accepted

Muthu, 03/30/07
Yes. This is the first place where it is mentioned. We have this fact later referred in Section 4.5 “The Default Context”, in Section 6.2 “Definitions” and Archival Applications section. Added internal links (see XXX) to these sections.

Email Trail:

Issue 51

From Grégory Pakosz, Vision Objects (2006-12-20):

contextRef = xsd:anyURI
The context associated with this traceGroup.
Required: no, Default: none
brushRef = xsd:anyURI
The brush associated with this traceGroup.
Required: no, Default: none
<traceGroup> element also defines "contextRef" and "brushRef" attributes: same question as for the <trace> element, what should we do when "contextRef" and "brushRef" are both defined but the "brushRef" or the <brush> of the corresponding <context> differs from the <traceGroup>'s "brushRef"? Actually the answer to this question seems to be given by a usage example in the 7.1 Archival Applications section.
If a trace includes both brushRef and contextRef attributes, the brushRef overrides any brush attributes given by the contextRef (see 4.3.1 <brush> element section).
Does it apply to <traceGroup> elements (see 3.3.1 traceGroup element)?

Resolution: Accepted

Muthu, 04/02/07
Yes. The documentation has to be updated to explicilty state the order of precedence: brushRef's override any brushes contained in a contextRef. brushRef's and contextRef's on <trace>'s override any specifications on <traceGroup>'s.

Email Trail:

Issue 90

From Grégory Pakosz, Vision Objects (2006-12-20):

There are examples for the identity and mathml mappings, but not for lookup, affine and product ones (see 6.1 Mappings).

Resolution: Accepted

6.1.2 <bind> has an example of "lookup". Corrected example in 6.1.3 to be "product". Added a "affine" example in 6.1.4 for <matrix>.

Email Trail:

Issue 106

From Grégory Pakosz, Vision Objects (2006-12-20):

A trace or traceGroup can both reference a context and override its brush, as in the following:
<trace xml:id="t001" contextRef="#context1" brushRef="#penA">...</trace>
<traceGroup contextRef="#context1" brushRef="#penA">
<trace xml:id="t002">...</trace>
</traceGroup>
which assigns the context specified by "context1" to traces "t001" and "t002", but with "penA" instead of the default brush.
Somehow, this behavior should be explicitly specified instead of being introduced at the end of the document, in a section giving usage examples.

Resolution: Accepted

We need to more clearly identify how context information is combined.

Explicility spelled out the order of precdence of contextRef versus brushRef, and the nesting of traceGroups and traces.

Email Trail:

Issue 107

From Grégory Pakosz, Vision Objects (2006-12-20):

Brushes, traceFormats, and contexts which appear outside of a <definitions> block and contain an id attribute both set the current context and define contextual elements which can be reused
It seems to answer my previous questions about references to elements that are not packed in to <definitions> blocks in the same document. Does it apply to elements defined in other documents ? I guess the answer is yes by nature of URIs.

Comment: Muthu, 04/02/07
But as per the spec, <brush> element can be defined only within <context> other than within <definitions> block. So in order to define a new brush, we have to create a <context> element with the new <brush> element definition??.

Resolution: Accepted

Added language to section 7 to clarify that streaming and archival.

Email Trail:

Issue 108

From Grégory Pakosz, Vision Objects (2006-12-20):

A <context> element can also override values of a previously defined context by including both a contextRef attribute and one or more of the canvasRef, canvasTransformRef, traceFormatRef or brushRef attributes. The following:

<context contextRef="#context1" brushRef="#penB"/>
Also answers my previous questions. Somehow, I guess it would be a good idea to specify these behaviors in the corresponding sections rather in the streaming application mode usage example.

Resolution: Accepted

Added language to section 7 to clarify that streaming and archival.

Email Trail:

Issue 143

From Grégory Pakosz, Vision Objects (2006-12-20):

Streaming how-to

I started having a look at the last draft of the InkML specification.
Before I send any feedback, I would like to know more about streaming mode since I'm not familiar at all with XML streaming:

- how is it done in practice ?
- does StAX need to be used or rather something like SOAP ?
- when you send continuation <trace> elements, do they have to be wrapped inside <ink></ink> markups ?

Resolution: Accepted

Added language to section 7 to clarify that streaming and archival.

Added comment to implementation guidelines saying that any of the usual XML protocols (StAX, SOAP, etc) may be used to transmit InkML documents or fragments between subprograms or distributed programs.

Email Trail:

Issue 179

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

Because this can be used in situation where the date of creation/capturing is important you should also proved a optional date Attribute.

Resolution: Rejected

A data attribute on <ink> would be redundant: we already have the <timestamp> element and timestamp attribute on trace.

Email Trail:

Issue 191

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

Type attribute definition: 'A value of "indeterminate" is used if the contact-state ... and may be either unknown or variable within the trace.'
The change of penup/pendown should force to a new trace. If the trace is of none contact(between pen and digitizer) it is pen up. If the pen is in contact with the digitizer it is pendown. In the example you give it is important to know if the pen has contact at tracing time or not and there is no other way to define this state. And i see no use case where a mix of pendown/penup is of no relevance or where the state can't be determined(the unknown state).

Resolution: Rejected

If the trace is a mid-trace in a set of trace continuations, the state can be "indeterminate". Its actual "penUp" or "penDown" state is determined by a prior trace.

Email Trail:

Issue 194

From Robert Vincenz <vincenz@snafu.de> (2010-06-09):

If any intermittent values are reported for the point, they are given next, in the order given by the <intermittentChannels> elements of the applicable <traceFormat>. Unreported intermittent channels are interpreted as though they were given by the wildcard "*".'This definition make it not clear if it is allowed to leave any channels away, when one is given. So here two questions :
1) is it OK to leave the channels away that follow the channel you give a value? (as i can see in the example it is OK)
2)is it OK to leave channels away before the one you give(that is not OK -> misinterpretation, but you do not forbid it)'
If any intermittent values are reported for the point, they are given next, in the order given by the <intermittentChannels> elements of the applicable <traceFormat>. Only intermittent channels that follows the last explicit given channels can be give away and are interpreted as though they were given by the wildcard "*".'

Resolution: Rejected

I believe the core issue is this: For a regular or intermittent channel, if a trace provides nothing but wildcards or nothing for a given channel, what is its value? The simple answer is 0 or F, depending on its data type. This is in fact what the Microsoft Office implementation does.

I don't feel this needs to be explicitly stated in the spec.

Email Trail: