W3C

Ink Markup Language (InkML) 1.0:
Implementation Report

Version: 20 April 2011

Contributors:

Stephen M. Watt, University of Western Ontario
Tom Underhill, Microsoft
Deborah Dahl, Invited expert
Kazuyuki Ashimura, W3C

Copyright © 2003-2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Table of Contents

1. Introduction

The InkML Specification entered the Candidate Recommendation period on 11 January 2011.

The planned date for entering Proposed Recommendation is 10 May 2011. This document summarizes the results from the InkML implementation reports received and describes the process that the Multimodal Working Group followed in preparing the report.

1.1 Implementation report objectives

  1. Must verify that the specification is implementable.

1.2 Implementation report non-objectives

  1. The IR does not attempt conformance testing of implementations.

2. Work during the Candidate Recommendation period

During the CR period, the Working Group carried out the following activities:

  1. Clarification and improvement of the exposition of the specification (http://www.w3.org/TR/2011/CR-InkML-20110111/).
  2. Disposing of comments that were communicated to the WG during the CR period. These comments
    and their resolution are detailed in the Disposition of Comments document for the CR period.
  3. Preparation of this Implementation Report.

3. Participating in the implementation report

Implementers were invited to contribute to the assessment of the W3C InkML 1.0 Specification by submitting implementation reports describing the coverage of their InkML implementations with respect to the test assertions outlined in the table below.

Implementation reports, comments on this document, or requests made for further information were posted to the Working Group's public mailing list www-multimodal@w3.org (archive).

4. Entrance criteria for the Proposed Recommendation phase

The Multimodal Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:

  1. Sufficient reports of implementation experience have been gathered to demonstrate that InkML processors based on the specification are implementable and have compatible behavior.
  2. Specific Implementation Report Requirements (outlined below) have been met.
  3. The Working Group has formally addressed and responded to all public comments received by the Working Group.

All three of these criteria have been met. A total of 4 implementations were received from 4 different companies and universities. The testimonials below indicate the broad base of support for the specification. All of the required features of InkML had at least two implementations, many had four implementations. All of the optional features received at least one implementation. However, these optional features do not have conformance requirements that have an impact on interoperability.

5. Implementation report requirements

5.1 Detailed requirements for implementation report

  1. Testimonials from implementers are included in the IR when provided to document the utility and implementability of the specification.
  2. IR must cover all specified features in the specification. For each feature the IR should indicate:
  3. Feature status is a factor in test coverage in the report:

5.2 Notes on testing

  1. A implementation report must indicate the outcome of evaluating the implementation with respect to each of the test assertions. Possible outcomes are "pass", "fail" or "not-impl". "

5.3 Out of scope

InkML Implementation Report will not cover:

6. Systems

This section contains testimonials on InkML from the 4 companies and universities that submitted InkML implementation reports.

Microsoft Corporation, USA

Exec Summary

Microsoft is committed to incorporating support for natural input into its products. Input methods such as ink handwriting and diagrams expand the types of content that can be created and stored in digital form. The usefulness of such information relies on the ability to create accurate interpretations of the data and the ability to persist these interpretations in an openly accessible format. As a member of the W3C Multimodal Interaction working group, Microsoft supports the Ink Markup Language (InkML) 1.0 Candidate recommendation as an effective approach to representing interpretations of natural input.

The InkML 1.0 standard provides a rich language for expressing the archiving or streaming of digital ink content. A key concern for Microsoft as the company moves to support open file and data exchange formats is that the standards which are ultimately adopted allow for the accurate representation of existing data, typically represented in proprietary binary formats. The proposed InkML standard, along with the related EMMA standard, provides the desired compatibility with existing Microsoft formats. As such, Microsoft believes that the adoption of these specifications will make natural input data available to a broader range of clients, ultimately making such data more useful and valuable.

University of Western Ontario, Canada

Exec Summary

The InkChat application provides a digital canvas that can be shared across platforms for remote collaboration. InkML provides the necessary platform-independent representation of digital ink. While the core language is simple, InkML is rich enough to support a broad range of devices, allowing high-fidelity capture and rendering.

The streaming features of InkML 1.0 allow InkChat to capture a written collaboration as it develops, record it, and play back an animation of the session, synchronized with the recorded conversation. The archival and annotation features allow our application to maintain a large collection of training samples to support our recognition engine.

InkML allows us to support multiple platforms and to future-proof our application.

Openstream Inc., USA

Exec Summary

Openstream is committed to making interaction on the move natural & convenient through its Cue-me(tm) Context-aware Multimodal Platform and solutions and continues to actively support the development and deployment of interoperable products and solutions that are based on Open standards.

As a participating member of the W3C Multimodal Interaction working group, Openstream supports the Ink Markup Language (InkML) 1.0 Candidate Recommendation as an effective approach towards providing natural interaction with software applications.

InkML1.0 together with related EMMA standard allows to create rich annotations for inputs of different modalities within a Multimodal Application using Open Data Format in a platform-independent way.

Openstream is very pleased to be able to contribute to the development and submit an InkML 1.0 Implementation Report which covers the relevant features for natural interaction in multimodal application development. InkML annotations of images is already available through Openstream's

Cue-me(tm) Context-aware Multimodal Platform and applications.

Openstream continues its commitment and participation in the evolution of this and other standards.

Hewlett-Packard Labs, India

Exec Summary

We found the specification to be sufficiently rich in structure to allow the representation of digital ink data with loss of fidelity. This allows the specification to be used to support a range of applications, from forensic analysis and whiteboard sharing to handwriting recognition and dataset creation. The description and examples in the specification are easy to understand. The core set of elements required for representing digital ink for basic applications is small, allowing novice developers to get started rapidly and use the more advanced aspects only as and when required. The specification includes ways of compressing digital ink payloads for transmission, and simplifies cross-platform uses of digital ink. At HP Labs India, we have used InkML for various applications such as pen-based form filling (http://www.youtube.com/watch?v=A6o702CECGk) and cross-platform collaborative inking (http://www.youtube.com/watch?v=LwigOiZt6jM), in tools for handwriting annotation, and to define UPX (http://unipen.nici.kun.nl/upx/) a proposed XML standard for online handwriting datasets .

7. Test results

The aim of this section is to describe the range of test assertions developed for the InkML 1.0 Specification and summarize the results from the implementation reports received in the CR period. The table lists all the assertions that were derived from the InkML 1.0 Specification.

The Assert ID column uniquely identifies the assertion. The Feature column indicates the specific elements or attributes which the test assertion applies to. The Spec column identifies the section of the InkML 1.0 Specification from which the assertion was derived. The REQ column is a Y/N value indicating whether the test assertion is for a feature which is required. The SUB column is a Y/N value indicating whether the test assertion is a sub constraint which is dependent on the implementation of the preceding non sub constraint feature test assertion. The Semantics column specifies the semantics of the feature or the constraint which must be met. The Result column is annotated with the number of 'pass', 'fail', and 'not implemented' (P/F/NI) in the set of implementation reports.

7.1 Classification of test assertions

Test assertions are classified into two types, basic test assertions which test for the presence of each feature, and sub constraints which only apply if that particular feature is implemented. Generally, sub constraints encode structural constraints that could not be expressed in the InkML schema. Sub constraints are marked with 'SUB CONSTRAINT:' in the Semantics field and 'Y' in the Sub field.

7.2 InkML Test assertion results

Assert ID Feature Spec Req Sub Semantics Results
P F NI
Ink and child elements, attributes
100 inkml:ink [2.1] Y N InkML documents MUST have inkml:ink as the root element. 4 0 0
101   [2.1] N Y SUB CONSTRAINT: The inkml:documentID attribute MAY be used to provide a unique id to the Ink document. 4 0 0
200 inkml:trace [3.2.1] Y N The inkml:trace MUST be used to record the data captured by the digitizer. 4 0 0
201   [3.2.1] Y Y

SUB CONSTRAINT: 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.  This subset of EBNF includes the following notation:

  • *: 0 or more
  • +: 1 or more
  • ?: 0 or 1
  • (): grouping
  • |: separates alternatives
  • double or single quotes surround literals
  • #x precedes hex character codes

The grammar is as follows:

trace   ::= point ("," point)* ","? wsp*

point   ::= (wsp* value)+ wsp*

value   ::= difference_order?  wsp* "-"? wsp* number | "T" | "F" | "*" | "?"

number  ::= (decimal | double | hex)

double  ::= decimal ("e"|"E") ("+"|"-")? digit+ 

decimal ::= digit+ ("." digit*)? | "." digit+

hex     ::= "#" (digit | "A" | "B" | "C" | "D" | "E" | "F")+

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

digit   ::= ("0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9")

wsp     ::= (#x20 | #x9 | #xD | #xA)
Additionally, wsp MAY occur anywhere except within a decimal, float or hex and MUST occur if required to separate two values. Otherwise the longest token is matched. For example, "3245" requires an internal wsp character if it is to be interpreted as two decimal numbers, "32" and "45". On the other hand, "0.923.45" will be interpreted as "0.923" and ".45".
 4 0 0
202   [3.2.1] Y Y SUB CONSTRAINT: The number of value tokens appearing within each point MUST be at least equal to the number of regular channels and be no more than the number of regular channels plus the number of intermittent channels. 2 1 1
203   [3.2.1] Y Y SUB CONSTRAINT: The sequence order of reported channels MUST be a head for the sequence of declared channels given in the applicable inkml:traceFormat. 3 0 1
204   [3.2.1] Y Y SUB CONSTRAINT: The priorRef attribute MUST be present for traces having value middle or end for the continuation attribute. 2 0 2
205   [3.2.1] Y Y SUB CONSTRAINT: All traces MUST begin with an explicit value, not with a first difference(' - single quote prefix) or second difference (" - double quote prefix). 4 0 0
206   [3.2.1] Y Y SUB CONSTRAINT: A second difference encoding MUST be preceded by a single difference representation; which, in turn, must be preceded with an explicit encoding. 3 0 1
207   [3.2.1] Y Y SUB CONSTRAINT: Intermittent channels MUST be always encoded explicitly, i.e. the qualifiers ' and " are not allowed. 2 0 2
208   [3.2.1] Y N The wildcard character "*" MUST be used to indicate either that the value of the channel remains at the previous channel value (if explicit), or that the channel continues integrating with the previous first difference or second difference values, as appropriate. 3 0 1
209   [3.2.1] Y Y SUB CONSTRAINT: All Channels declared after the last reported channel MUST be treated as though a '*' were reported. All channels declared before the last reported channel must also be reported, if only with explicit wild cards. 2 0 2
210   [3.2.1] Y N The wildcard character "?" MUST be used to indicate that value of a channel is not given at that point. 3 0 1
300 inkml:traceGroup [3.3.1] Y N Successive inkml:trace which share common characteristics MAY be grouped using an inkml:traceGroup. 4 0 0
301   [3.3.1] Y Y SUB CONSTRAINT: The inkml:contextRef attribute MUST be used to refer to the inkml:context element defining the common contextual values of the trace data grouped by the inkml:traceGroup. 3 1 0
302   [3.3.1] Y N A inkml:traceGroup element MUST support nested inkml:trace elements or inkml:traceGroup elements as children. 4 0 0
303   [3.3.1] N N Semantic Labeling:  An inkml:annotation element or an inkml:annotationXML element MAY be given as child to inkml:traceGroup and contains semantic of the grouped set of traces. For example the recognition results of the logical group of traces that belongs to a word can be captured using the annotation element. 3 0 1
400 inkml:traceView [3.3.2] N N The inkml:traceView element MAY be used to group traces by reference from the current document or other documents. 2 0 2
401   [3.3.2] N Y SUB CONSTRAINT: The inkml:traceDataRef attribute MAY be used to specify the URI of a inkml:trace, inkml:traceGroup or inkml:traceView element. 1 0 3
402   [3.3.2] N Y SUB CONSTRAINT: The grouping MAY be used to provide common contextual values or structure for semantic labeling. Additional context information MAY be supplied via <annotation> or <annotationXML> child elements. 1 0 3
405   [3.3.2] N Y SUB CONSTRAINT: If a traceDataRef attribute is given, then a to and/or from attribute MAY be given. Together, traceDataRef, from and to attributes refer to another trace data element and select part of it. 2 0 2
406   [3.3.2] N Y SUB CONSTRAINT: A missing from attribute MAY be equivalent to selecting the first point in the (recursively) first child of the referenced element. A missing to attribute MAY be equivalent to selecting the last point in the (recursively) last child of the referenced element. 2 0 2
407   [3.3.2] N Y SUB CONSTRAINT: Interpretation logic of from or to attributes: Any value of a from or to attribute is a colon-separated list of integers, whose meaning MAY be defined as follows: An empty list of integers SHOULD select the entire referenced object (point, <trace>, <traceGroup> or <traceView>). If the list is non-empty, then its first element SHOULD be taken as a 1-based index into the referenced object, and the remaining list is used to select within the object. 1 0 3
407a   [3.3.2] N Y SUB CONSTRAINT: It SHOULD be considered as ERROR to try to select within a single point. 2 0 2
408   [3.3.2] N Y SUB CONSTRAINT: If the referenced object is a traceView, then the indexing MAY be relative to the tree selected by the traceView, not relative to the original traceView object. 2 0 2
409   [3.3.2] N Y SUB CONSTRAINT: If a contextRef attribute is given, then it MAY override the context of the referenced trace data. 1 0 3
410   [3.3.2] N Y SUB CONSTRAINT: If a <traceGroup> contains continuation traces, they MAY be counted independently, i.e. each continuation trace is a separate element. 1 0 3
500 inkml:definitions [6.2.1] Y N The inkml:definitions element MAY be used as a container which is used to define reusable content such as Contextual elements. 4 0 0
501   [6.2.1] Y Y SUB CONSTRAINT: Child Elements of inkml:definitions  MUST have an xml:id attribute in order to allow them to be referenced. 4 0 0
502   [6.2.1] Y N Content within a <definitions> has no impact on the interpretation of traces, unless referenced from outside the <definitions>. 4 0 0
503   [6.2.1] Y N Multiple inkml:definitions as children to the root inkml:ink element SHOULD be accumulated into a single definition-state of that ink document. 4 0 0
600 inkml:context [4.1] Y N The inkml:context MUST be used to consolidate all salient characteristics of one or more related ink traces. 3 0 1
601   [4.5] Y N Default Context: Implicit references to context attributes MUST be referred to default context. The current context must be initialized with default value for all properties, including default trace format, default canvas, etc. Then, interspersed with ink data, other elements may occur that alter the default context. 4 0 0
602   [4.5] Y N The default context MAY be explicitly specified using the URI "#DefaultContext". 3 0 1
Context child elements and attributes
700 inkml:traceFormat [3.1.1] Y N The inkml:traceFormat describes the format used to encode points within inkml:trace elements. It MUST contain an ordered sequence of inkml:channel elements, giving the regular channels (if any), followed by an optional inkml:intermittentChannels. 4 0 0
701   [3.1.1] Y Y SUB CONSTRAINT: The order of the coordinates in each point of a trace MUST be determined by the order of the inkml:channel elements in the trace format, including those from the intermittent channels part. 4 0 0
702   [3.1.1] Y N Default Trace Format: If no inkml:traceFormat is not specified, then a default traceFormat with id attribute equal to DefaultTraceFormat which has the channels X and Y with default values for the attributes. 4 0 0
800 inkml:intermittentChannels [3.1.3] Y N The inkml:intermittentChannels MUST contain those inkml:channel elements whose value may optionally be recorded for each sample point. 3 0 1
801   [3.1.3] Y Y SUB CONSTRAINT: The order of the enclosed inkml:channel declarations MUST give the order of the intermittent channel data samples within traces referring the enclosing inkml:traceFormat element. 3 0 1
802   [3.1.3] N Y SUB CONSTRAINT: The child inkml:channel MAY use the default attribute to specify the default value for the channel which if not given SHOULD be 0 (for integer or decimal channel), F (for boolean channel). 2 0 2
900 inkml:channel [3.1.2] Y N The list of channels provided by the digitizing device or any inkSource system MUST be mapped to a list of inkml:channel elements wrapped in to a inkml:traceFormat element and in the optional inkml:intermittentChannels child element of the traceFormat. 3 0 1
901   [3.1.2] Y N The name attribute MUST be used to provide name for the channel. It should be used as key for referring to the channel. 4 0 0
902   [3.1.2] Y N The type attribute MAY be used to provide the data type of the channel. It can have any one of the relevant value from, "integer", "decimal" and "boolean". If the attribute is not specified, then "decimal" SHOULD be assigned as default value. 4 0 0
903   [3.1.2] Y N The min attribute MAY be used to provide the lower boundary value of the channel. The max attribute MAY be used to provide the upper boundary value of the channel. 4 0 0
904   [3.1.2] Y Y SUB CONSTRAINT: If  the min and max attributes are given, then all channel values MUST fall within the specified range. 2 0 2
905   [3.1.2] N N The orientation attribute MAY be used to specify the orientation of increasing channel values with respect to the default direction of the channel's coordinate axis. The possible values are either "+ve" or "-ve". The default value SHOULD be "+ve". 3 0 1
906   [3.1.2] N N The respectTo attribute MAY be used to provide a 'frame of reference' data for the channel. For example, it MAY be used to provide the 'origin' value for numerical channels such as X and Y and MAY be used to specify the 'reference timeStamp' for the Time channel (T). 3 0 1
907   [3.1.2] N N The units attribute MAY be used to provide the unit value of numerical channels (type attribute is either "integer" or "decimal"). 4 0 0
908   [3.1.2] N Y SUB CONSTRAINT: In scenarios where the channel value reported by the digitizer is preprocessed/normalized to get the channel value of the trace data,  a child inkml:mapping element MAY be used to specify the correspondence between those channel values. e.g. A mapping child element MAY be used with any 'orientation channels' to map the angles to the sin of the angles, as this is usually more useful in calculation involving angles. 1 0 3
909   [3.1.2] Y N Reserved Channel Names: The list of reserved channel names given in the specification MUST be implemented with the semantic as explained in the specification. 4 0 0
910   [3.1.2] N Y SUB CONSTRAINT: The inkml:mapping child element MAY be used to define the transformation for normalizing the device reported channel value to the this channel value. The corresponding source channel description is already given in the inkml:inkSource element in the current context.  1 0 3
911   [3.1.8] Y N User Defined Channels: User MAY define new inkml:channel elements apart from the list of reserved channels available. e.g. When using direction-sensitive stylus, the force channel MAY be measured using 3 user defined channels such as FX, FY and FZ. 4 0 0
1000 inkml:inkSource [4.2.1] Y N The metadata about the format and quality of ink as it is reported by the source MUST be captured using an inkml:inkSource element. The source is typically hardware (a digitizer device), but may in general be any "virtual" source of ink, such as a software application that is tracking the trajectory of an object. 4 0 0
1001   [4.2.1] Y Y SUB CONSTRAINT: The inkml:traceFormat child element MUST be used to define the format of the ink.  4 0 0
1002   [4.2.1] N Y SUB CONSTRAINT: The specificationRef attribute MAY have an URI of a page that used to provide detailed or additional specifications. 2 0 2
1100 inkml:canvas [5.1] N N The inkml:canvas element MAY be used to define a virtual coordinate system, which uniquely identifies a shared virtual space for cooperation of ink applications. 2 0 2
1101   [5.1] N N The inkml:canvas MAY define its dimension by giving a inkml:traceFormat element. The channel definition contains the min and max values, orientation and units. 2 0 2
1102   [5.1] N Y SUB CONSTRAINT: The "traceFormatRef" attribute MAY be used to refer the pre-existing trace format element. 1 0 3
1103   [5.1] Y N Default Canvas: The default canvas MUST be available as part of the Default Context. It SHOULD have two real-valued coordinates X and Y, both unbounded in the positive and negative directions. 3 0 1
1104   [5.1] N Y SUB CONSTRAINT: The default canvas MAY be explicitly specified using the URI "#DefaultCanvas". 3 0 1
1200 inkml:canvasTransform [5.2] N N The inkml:canvasTransform element MAY be used to relate two coordinate systems. The source and target coordinate systems SHOULD be defined in terms of inkml:traceFormat elements. 2 0 2
1201   [5.2] N N The contents of the <canvasTransform> MAY consist of one or two inkml:mapping elements.  If there is only one, then it SHOULD be the mapping from the source to the target coordinate system, where the meaning of "source" and "target" is determined by the use. If there are two children, the first SHOULD be the mapping from the source to the target and the second SHOULD the inverse mapping from the target back to the source. 2 0 2
1202   [5.2] N N The inverse transform MAY map from the canvas back to the original trace format by supplying default values for the coordinates not in the canvas 1 0 3
1203   [5.2] N N For certain classes of mappings, the inverse mapping MAY be determined automatically in which case the invertible attribute MUST be set to true. 2 0 2
1204   [5.2] N N The Mappings Should be one of the below types, "identity" , "lookup", "affine", "mathml", and "product". Otherwise the type MUST be treated as "unknown". 1 0 3
1205   [5.2] N N Default Canvas Transform: The default canvasTransform SHOULD have "identity" mapping for both forwarded and inverse mapping. 2 0 2
1300 inkml:brush [4.3.1] Y N The inkml:brush element MAY be used for the definition of reusable set of brush attributes which may be associated with traces. 4 0 0
1301   [4.3.1] Y N The xml:id attribute MUST be present and uniquely identify the brush. 3 1 0
1302   [4.3.1] Y N The "brushRef" attribute MAY be present to reference another brush whose attributes this brush inherit. 4 0 0
1303   [4.3.1] Y Y SUB CONSTRAINT: if the brush inherits properties from another brush reference via a "brushRef" attribute, and if any of the same properties are also defined on this brush via inkml:brushProperty child elements, the local brushProperty values override the inherited values. 3 0 1
1304   [4.3.1] Y N A "brushRef" attribute on a inkml:context element MAY reference a brush and any traces which reference the context MUST be assigned the brush attributes of the referenced brush. 4 0 0
1305   [4.3.1] Y Y SUB CONSTRAINT: A "brushRef" attribute on a inkml:trace element MAY reference a brush and this brush assignment MUST override any brush assignment specified by the trace's context. 4 0 0
1350 inkml:brushProperty [4.3.2] Y N The list of brush attributes MUST be specified using inkml:brushProperty child elements. 3 0 1
1351   [4.3.2] Y N The "name" attribute specifying a brush property name MUST be present on a inkml:brushProperty element. 3 0 1
1352   [4.3.2] Y N The application MUST support the list of "name" attribute values listed in section: "width", "height", "color", "transparency", "tip", "rasterOp", "antiAliased", "fitToCurve", "ignorePressure".  The application MAY use additional "name" attribute values. 3 0 1
1352   [4.3.2] Y N The value attribute specifying a brush property value MUST be present and the data type must be appropriate for the give brush property type specified by the "name" attribute. 3 0 1
1353   [4.3.2] Y Y SUB CONSTRAINT: The "unit" attribute specifying a brush property value's particular unit of measure MAY be present, but if present the "value" attribute MUST be a numeric value. 2 0 2
1400 inkml:timestamp [4.4.1] N N The inkml:timestamp element MAY be used define a reference timestamp which can then be used for relative timestamping of traces. 1 0 3
1500 inkml:sampleRate [4.2.2] N N The inkml:sampleRate element MAY be used to capture the rate at which ink samples are reported by the ink source device. 2 0 2
1501   [4.2.2] N Y SUB CONSTRAINT: The value attribute MUST be given a decimal value equals to the sample rate in samples/second. 2 0 2
1502   [4.2.2] N Y SUB CONSTRAINT: The uniform attribute MUST be designated "false" (non-uniform) if any pen-down points are skipped or if the sampling is irregular. 1 0 3
1510 inkml:latency [4.2.3] N N The inkml:latency element MAY be used to capture the basic device latency that applies to all channels, in milliseconds. 1 0 3
1511   [4.2.3] N Y SUB CONSTRAINT: The value attribute MUST be given a decimal value equals to the latency in milliseconds. 1 0 3
1520 inkml:activeArea [4.2.4] N N The inkml:activeArea element MAY be used to encode the details of the two-dimensional area within which the source device is capable of sensing the pen position. 1 0 3
1530 inkml:srcProperty [4.2.5] N N The basic device details of inkml:inkSource are captured using inkml:sampleRate, inkml:latency and inkml:activeArea child elements. All other additional 'numeric' properties MAY be captured using inkml:srcProperty elements. 2 0 2
1540 inkml:channelProperty [4.2.7] N N The inkml:channelProperty element MAY be used to define additional properties to inkml:channel elements other than that provided with attributes of the inkml:channel element. 3 0 1
1550 inkml:channelProperties [4.2.6] N N This child element of inkml:inkSource element MAY be used to wrap inkml:channelProperty elements that define additional properties to inkml:channel which are defined in traceFormat of the inkSource. 3 0 1
1560 inkml:mapping [6.1] N N The inkml:mapping element MAY be used to define transformational mapping of different trace formats. 2 0 2
1570 inkml:bind [6.1.2] Y N For a lookup table, each index column MUST be bound to the channel that provides the input for the lookup operation. This MAY be done with a <bind> element that specifies source and column attributes. 2 0 2
1580 inkml:table [6.1.3] N N A table MAY be used to provides a set of points for mapping. 1 0 3
1581   [6.1.3] Y Y SUB CONSTRAINT: Each row MUST have the same number of entries. The final row MAY optionally be followed by a comma. 1 0 3
1582   [6.1.3] N N Each row in the table MAY represent a value of the function at one point. Which columns represent the argument (s) and which the result (s)  MAY be determined by <bind> elements. 1 0 3
1583   [6.1.3] N Y SUB CONSTRAINT: The entries in the table may either be all numerical or all boolean. 1 0 3
1584   [6.1.3] N N The "interpolation" attribute  MAY be used to specify the interpolation between discrete mapping values defined by a lookup table. 1 0 3
1585   [6.1.3] Y Y SUB CONSTRAINT: The possible values for the "interpolation" attribute are "floor, middle, ceiling, linear and cubic". The default value for the attribute MUST be "linear". 1 0 3
1586   [6.1.3] N N The "apply" attribute MAY be used to specify whether the mapping values are used from the table/formula, or whether this table/formula needs to be added to the current data value. 1 0 3
1587   [6.1.3] Y Y SUB CONSTRAINT: The possible values for the "apply" attribute are "absolute" and "relative" . The default value for the attribute MUST be "absolute". 1 0 3
1590 inkml:affine [6.1.4] N N The inkml:affine element MAY be used to provide the entries for an affine mapping from n source values to m target values. 1 0 3
1591   [6.1.4] Y Y SUB CONSTRAINT: An affine mapping MUST consists of a linear transformation (multiplication by a matrix) and a shift (adding a vector). 1 0 3
Annotation elements
1600 inkml:annotation [6.3.1] N N The inkml:annotation element MAY be used to annotate with simple textual descriptions in the ink markup. 2 0 2
1610 inkml:annotationXML [6.3.2] N N The inkml:annotationXML element MAY be used to annotate with a collection of XML elements as content (children) for example, a MathML markup or any valid well formed XML snippet. 3 0 1
Common Attributes
1700 xml:id attribute   Y Y SUB CONSTRAINT: Any InkML element that have a non-empty xml:id attribute MUST be persisted in to inkml:definitions and be available for reference by other elements. 4 0 0
1710 inkml:units attribute [6.4] N N The inkml:units attribute MAY be used in inkml:channel (numerical-channel) to indicate the unit of the channel value and MAY be used in inkml:channelProperties element to provide unit for channel properties.  3 0 1
1711   [6.4] Y Y SUB CONSTRAINT: An enumerated list of values given in the specification MUST be supported  as value for inkml:units attribute. 2 0 2

Appendices

Appendix A - Acknowledgements

The Multimodal Working Group would like to acknowledge the contributions of several individuals: