Ink Markup Language (InkML)

1 Overview

As more electronic devices with pen interfaces have and continue to become available for entering and manipulating information, applications need to be more effective at using this method of input. Handwriting is a powerful and versatile input modality that is very familiar for most users since everyone learns to write in school. Hence, users will tend to use this as a mode of input and control when available.

A pen-based interface is enabled by a device that allows movements of the pen to be captured as digital ink. A number of methods may be used for ink capture, including those based on radio frequency, optical tracking, physical pressure, or other technologies. Digital ink can be passed on to recognition software that will convert the pen input into appropriate computer actions. Alternatively, the handwritten input can be organized into ink documents, notes or messages that can be stored for later retrieval or exchanged through telecommunications means. Such ink documents are appealing because they capture information as the user composed it, including text in any mix of languages and drawings such as equations and graphs.

Hardware and software vendors have typically stored and represented digital ink using proprietary or restrictive formats. The lack of a public and comprehensive digital ink format has severely limited the capture, transmission, processing, and presentation of digital ink across heterogeneous devices developed by multiple vendors. In response to this need, the Ink Markup Language (InkML) provides a simple and platform-neutral data format to promote the interchange of digital ink between software applications.

InkML supports a complete and accurate representation of digital ink. In addition to the pen position over time, InkML allows recording of information about device characteristics and detailed dynamic behavior to support applications such as handwriting recognition and authentication. For example, there is support to record additional information such as pen tilt and pen tip force (often referred to as "pressure") and information about the recording device such as accuracy and dynamic distortion. InkML also provides features to support rendering of digital ink captured optically to approximate the original appearance. For example, stroke width and color information can be recorded.

It is not within the design 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.  However, InkML provides means for extension.  InkML can include XML from other schemas at specific locations in a file or stream (see <annotationXML>.)  Additionally, InkML could be embedded within other XML documents.

1.1 Uses of InkML

With the establishment of a non-proprietary ink standard, a number of applications, old and new, are expanded where the pen can be used as a very convenient and natural form of input. Here are a few examples.

• Ink Messaging

  Two-way transmission of digital ink, possibly wireless, offers mobile-device users a compelling new way to communicate. Users can draw or write with a pen on the device's screen to compose a note in their own handwriting. Such an ink note can then be addressed and delivered to other mobile users, desktop users, or fax machines. The recipient views the message as the sender composed it, including text in any mix of languages and drawings.

• Ink and SMIL

  A photo taken with a digital camera can be annotated with a pen; the digital ink can be coordinated with a spoken commentary. The ink annotation could be used for indexing the photo (for example, one could assign different handwritten glyphs to different categories of pictures).

• Ink Archiving and Retrieval

  A software application may allow users to archive handwritten notes and later retrieve them by a variety of mechanisms.

• Electronic Form-Filling

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

• Pen Input and Multimodal Systems

  Robust and flexible user interfaces can be created that integrate the pen with other input modalities such as speech. Multimodal applications may share context information across modalities, leading to better recognition in each modality individually.  In this setting, pen input may be used to disambiguate voice recognition and vice-versa.

1.2 Elements

The current InkML specification defines a set of primitive elements sufficient for all basic ink applications. All content of an InkML document is contained within a single <ink> element. The fundamental data element in an InkML file is the <trace>. A trace represents a sequence of contiguous ink points, where each point captures the values of particular quantities such as the X and Y coordinates of the pen's position. A sequence of traces accumulates to meaningful units, such as characters, words or diagrams.

In its simplest form, an InkML file with its enclosed traces looks like this:

<ink xmlns="http://www.w3.org/2003/InkML">
   <trace>
      10 0, 9 14, 8 28, 7 42, 6 56, 6 70, 8 84, 8 98, 8 112, 9 126, 10 140,
      13 154, 14 168, 17 182, 18 188, 23 174, 30 160, 38 147, 49 135,
      58 124, 72 121, 77 135, 80 149, 82 163, 84 177, 87 191, 93 205
   </trace>
   <trace>
      130 155, 144 159, 158 160, 170 154, 179 143, 179 129, 166 125,
      152 128, 140 136, 131 149, 126 163, 124 177, 128 190, 137 200,
      150 208, 163 210, 178 208, 192 201, 205 192, 214 180
   </trace>
   <trace>
      227 50, 226 64, 225 78, 227 92, 228 106, 228 120, 229 134,
      230 148, 234 162, 235 176, 238 190, 241 204
   </trace>
   <trace>
      282 45, 281 59, 284 73, 285 87, 287 101, 288 115, 290 129,
      291 143, 294 157, 294 171, 294 185, 296 199, 300 213
   </trace>
   <trace>
      366 130, 359 143, 354 157, 349 171, 352 185, 359 197,
      371 204, 385 205, 398 202, 408 191, 413 177, 413 163,
      405 150, 392 143, 378 141, 365 150
   </trace>
</ink>

These traces consist simply of X and Y value pairs, and may look like this when rendered:

Figure 1 shows a trace of a sampled handwriting signal. The dots mark the sampling positions which were interpolated by the blue line. Green points represent pen-downs whereas red dots indicate pen-ups.

Information about the device used to collect the ink (e.g., the sampling rate and resolution) may be specified with the <inkSource> element.

Ink traces can have certain attributes such as color and width, writer identification, pen modes (eraser versus writing), and so on. These and other attributes are captured using the <brush> element. Traces that share the same characteristics, such as being written with the same brush, can be grouped together with the <traceGroup> element.

In all appropriate cases, the InkML specification defines default values for elements that are not specified, and rules that establish the scope of a given attribute.

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

1.3 Exchange Modes

Most ink-related applications fall into two broad categories: "Streaming" and "Archival". Archival ink applications capture and store digital ink for later processing, such as document storage/retrieval applications and batch forms processing . In these applications, an entire <ink> element is written prior to processing. For ease of implementation in archival mode, referenced elements should be defined inside a declaration block using the <definitions> element (see The Default Context section, the Definitions section, and the Archival Applications section).

Streaming ink applications, on the other hand, transmit digital ink as it is captured, such as in the electronic whiteboard example mentioned above. In order to support a streaming style of ink markup generation, the InkML language supports the notion of a "current" state (e.g., the current brush) and allows for incremental changes to this state.

<ink xmlns="http://www.w3.org/2003/InkML"
    documentID="uuid:6B29FC40-CA47-1067-B31D-00DD010662DA">
   ...
</ink>

3 Traces and Trace Formatting

<trace> is the basic element used to record the trajectory of a pen as the user writes digital ink. More specifically, these recordings describe sequences of connected points. On most devices, these sequences of points will be bounded by pen contact change events (pen-up and pen-down), although some devices may simply record proximity and force data without providing an interpretation of pen-up or pen-down state.

The simplest form of encoding specifies the X and Y coordinates of each sample point. For compactness, it may be desirable to specify absolute coordinates only for the first point in the trace and use delta-x and delta-y values to encode subsequent points. Some devices record acceleration rather than absolute or relative position; some provide additional data that may be encoded in the trace, including Z coordinates or tip force, or the state of side switches or buttons.

These variations in the information available from different ink sources, or needed by different applications, are supported in InkML through the <traceFormat> and <trace> elements. The <traceFormat> element specifies the encoding format for each sample of a recorded trace, while <trace> elements are used to represent the actual trace data. If no <traceFormat> is specified, a default encoding format of X followed by Y coordinates is assumed.

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.

A channel can be characterized as either regular, meaning that its value is recorded for every sample point of the trace, or intermittent, meaning that its value may change infrequently and thus will not necessarily be recorded for every sample point. X and Y coordinates are examples of likely regular channels, while the state of a pen button is likely to be an intermittent channel.

3.1 Trace Formats

3.1.1 <traceFormat> element

Attributes:

Contents:

The <traceFormat> element describes the format used to encode points within <trace> elements. In particular, it defines the sequence of channel values that occurs within <trace> elements. The order of declaration of channels in the <traceFormat> element determines the order of appearance of their values within <trace> elements.

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 <context> element may use the traceFormatRef attribute to refer to a <traceFormat> by it's id.  If no <traceFormat> is specified 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".

3.1.2 <channel> element

Attributes:

Contents:

Channels are described using the <channel> element, with various attributes.

The required name attribute specifies the interpretation of the channel in the trace data. The following case sensitive channel names, with their specified meanings, are reserved:

The type attribute defines the encoding type for the channel (either boolean, decimal, or integer). If type is not specified, it defaults to decimal.

A default value can be specified for the channel using the default attribute; the use of default values within a trace is described in the next section. If no default is specified, it is assumed to be zero for integer and decimal-valued channels, and false for boolean channels.

Typically, a channel in the <traceFormat> will map directly to a corresponding channel provided by the digitizing device, and its values as recorded in the trace data will be the original channel values recorded by the device. However, for some applications, it may be useful to store normalized channel values instead, or even to remap the channels provided by the digitizing device to different channels in the trace data. This correspondence between the trace data and the device channels is recorded using a <mapping> element (described in the Mappings section) within the <channel> element. If no mapping is specified for a channel, it is assumed to be unknown.

3.1.3 <intermittentChannels> element

Attributes:

Contents:

The <intermittentChannels> element lists those channels whose value may optionally be recorded for each sample point.  The order of the enclosed channel declarations gives the order of the intermittent channel data samples within traces having this format.  The <intermittentChannels> section is optional and must appear after the regular <channel> elements (if any) within a <traceFormat> element.

3.1.4 Orientation Channels

The channels OTx, OTy, OA, OE and OR record pen orientation data. Implementers may choose to use either pen azimuth OA and pen elevation OE, or alternatively tilt angles OTx and OTy. The latter are the angles of projections of the pen axis onto the XZ and YZ planes, measured from the vertical. 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. While it is not forbidden to use channels from different groups together (i.e. from more than one of {OA, OE} and {OTx, OTy}), applications will not normally do this.

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.

Figure 2a displays the pen orientation using Azimuth and Elevation. The origin of the Azimuth is at the Y-axis. Azimuth increases anticlockwise up to 360 degrees. The origin of Elevation is located within the XY-plane. Elevation increases up to 90 degrees, at which point the pen is perpendicular to the XY-plane.

Figure 2b explains the definition of the Tilt-X and the Tilt-Y angles. For both the origin is along the Z-axis. Tilt-X increases up to +90 degrees for inclinations along the positive X-axis and decreases up to -90 degrees for inclinations along the negative X-axis. Respectively, Tilt-Y is defined for pen inclinations along the Y-axis.

Figure 3a displays the pen orientation decomposition as functions of Azimuth/Elevation or alternatively as function of Tilt-X/Tilt-Y. Thereby, elevations of the pen which are mapped to the XZ- and to the YZ- plane lead to Tilt-X and Tilt-Y.

Figure 3b shows the Rotation of the pen along its longitudinal axis.  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.

3.1.6 Width Channels

3.1.7 Time Channel

The time channel allows for detailed recording of the timing information for each sample point within a trace. This can be useful if the digitizing device has a non-uniform sampling rate, for example, or in cases where duplicate point data is removed for the sake of compactness.

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

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.

The units attribute gives the units of the recorded time values, and the respectTo attribute describes the frame of reference for those recorded values. The value of the respectTo attribute is a reference to a time stamp. If it is not given, the time channel values are relative to the beginning timestamps of the individual traces in which they appear.

<channel name="T"
         type="integer"
         units="ms"
         respectTo="#ts1" />

If no <traceFormat> information is provided, or if no value is specified for the respectTo attribute, the ink processor cannot make any assumption about the relative timing of points within different traces. Likewise, if no units are specified, no assumption can be made about the units of the time channel data.

3.1.8 User Defined Channels

In addition to the pre-defined channels, user-defined channels are allowed, although their interpretation is not required by conforming ink markup processors.

3.1.9 Specifying Trace Formats

The following example defines a <traceFormat> which reports decimal-valued X and Y coordinates for each point, and intermittent boolean values for the states of two buttons B1 and B2, which have default values of F ("false"):

<traceFormat xml:id="xyb1b2">
   <channel name="X" type="decimal">
      <mapping type="identity"/>
   </channel>
   <channel name="Y" type="decimal">
      <mapping type="identity"/>
   </channel>

   <intermittentChannels>
      <channel name="B1" type="boolean" default="F">
         <mapping type="identity"/>
      </channel>
      <channel name="B2" type="boolean" default="F">
         <mapping type="identity"/>
      </channel>
   </intermittentChannels>
</traceFormat>

The appearance of a <traceFormat> element in an InkML file both defines the format and installs it as the current format for subsequent traces except within a <definitions> block (see Specifying Trace Formats). The id attribute of a <traceFormat> allows the format to be reused by multiple contexts (see the Context section). 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>

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

3.2 Traces

Contents:

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)

The <trace> element is used to record the data captured by the digitizer. It contains a sequence of points encoded according to the specification given by the <traceFormat> element.

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 values of the tip switch state channel "S", if present in the trace, overrides the value of the type attribute.

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: the current trace is the first of the set of continuation traces
• end: the current trace is the last of the set of continuation traces
• middle: the current trace is a continuation trace, but is neither the first nor the last in the set of traces

If the current trace is a continuation trace but is not the first trace in the set (i.e. the continuation attribute has value middle or end) then a priorRef attribute must be present and must contain the URI of the trace of which the current trace is a continuation. A begin or middle trace can be the prior trace for exactly one trace. An end trace cannot be the prior trace of any other trace.

Regular channels may be reported as explicit values, differences, or second differences: Prefix symbols are used to indicate the interpretation of a value: a preceding exclamation point (!) indicates an explicit value, a single quote (') indicates a single difference, and a double quote prefix (") indicates a second difference. If there is no prefix, then the channel value is interpreted as explicit, difference, or second difference based on the last prefix for the channel. If there is no last prefix, the value is interpreted as explicit.

A second difference encoding must be preceded by a single difference representation; which, in turn, must be preceded with an explicit encoding.

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.  This is true for continuation traces.

Both regular and intermittent channels may be encoded with the wildcard character "*". This wildcard character means either that the value of the channel remains at the previous channel value (if explicit), or that the channel continues integrating with the previous velocity or acceleration values, as appropriate.

<trace> 11 12 9, 21 22 ? T, 31 32, 41 42 5, 51 52 ? F</trace>

Booleans are encoded as "T" or "F".

For each point in the trace, regular channel values are reported first in the order given by the <channel> elements of the applicable <traceFormat>. All regular channels must be reported, if only with the explicit wildcard "*".  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 "*".

Here is an example of a trace of 11 points, using the following traceFormat:

<traceFormat>
   <channel name="X" type="decimal"/>
   <channel name="Y" type="decimal"/>

   <intermittentChannels>
      <channel name="B1" type="boolean" default="F"/>
      <channel name="B2" type="boolean" default="F"/>
   </intermittentChannels>
</traceFormat>

<trace xml:id="id4525abc">
   1125 18432,'23'43,"7"-8,3-5,7 -3,6 2,6 8,3 6 T,2 4*T,3 6,3-6 F F
</trace>

The trace is interpreted as follows:

An ink markup generator might also include additional whitespace formatting for clarity. The following trace specification is identical in meaning to the more compact version shown above:

<trace xml:id="id4525abc">
   1125 18432,
   '23 '43,
   "7 "-8,
   3 -5,
   7 -3,
   6 2,
   6 8,
   3 6 T,
   2 4 * T,
   3 6,
   3 -6 F F
</trace>

3.3.1 <traceGroup> element

Attributes:

Contents:

The <traceGroup> element is used to group successive traces which share common characteristics, such as the same <traceFormat>. The brush and context sections describe other contextual values that can be specified for a <traceGroup>. In the following example the two traces enclosed in the <traceGroup> share the same brush (see the Brushes section for a description of brushes).

<traceGroup brushRef="#penA">
    <trace>...</trace>
    <trace>...</trace>
</traceGroup>

The <traceGroup> element may be used for various purposes, such as to group traces according to their properties at the time of capture or according to computed recognition results. The element may be nested, and it may be used as a generic grouping mechanism, e.g. for the semantic labeling of traces.

Trace groups are the primary mechanism for assigning <context> to traces in archival ink markup. For additional details about this usage, see the Archival Applications section.

<ink xmlns="http://www.w3.org/2003/InkML">
   <trace xml:id="L1">911 912, 921 922, 931 932</trace>

   <traceGroup xml:id="L2">
      <trace>111 112, 121 122</trace>
      <traceGroup xml:id="L2-Larry">
         <trace>221 212, 221 222</trace>
         <trace>311 312, 321 322</trace>
      </traceGroup>
      <trace>411 412, 421 422</trace>
      <traceGroup>
         <traceGroup>
            <trace xml:id="L2-Moe">521 512, 521 522</trace>
            <trace>611 612, 621 622</trace>
         </traceGroup>
      </traceGroup>
      <trace>711 712, 721 722</trace>
   </traceGroup>

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

   <traceView xml:id="L4" traceDataRef="#L3" from="1:2" to="2:1:2:1"/>
</ink>

<traceGroup>
   <trace>921 922, 931 932</trace>

   <traceGroup>
      <traceGroup>
         <trace>221 212, 221 222</trace>
         <trace>311 312, 321 322</trace>
      </traceGroup>
      <trace>411 412, 421 422</trace>
      <traceGroup>
         <traceGroup>
            <trace>521 512, 521 522</trace>
         </traceGroup>
      </traceGroup>
   </traceGroup>

</traceGroup>

<traceGroup>
   <trace>931 932</trace>
   <traceGroup>
      <traceGroup>
         <trace>221 212, 221 222</trace>
         <trace>311 312</trace>
      </traceGroup>
   </traceGroup>
</traceGroup>

4 Contexts

The context in which ink is written and recorded comprises many details. Examples include the size of the surface the traces were recorded on, the pen tip used or the accuracy of the pressure measurements. This contextual information needs to be captured by InkML in order to fully characterize the recorded ink data. This section defines markup that provides a way to describe this information, including the <context> element which provides a means to associate a defined context with trace data.

4.1 The <context> element

This section describes the <context> element and its attributes. The context element both provides access to a useful shared context (canvas) and serves as a convenient agglomeration of contextual attributes. It is used by the <traceGroup> and <traceView> elements to define the complete shared context of a group of traces or may be referred to as part of a context change in streaming mode. In either mode, individual attributes may be overridden at time of use. Additionally, individual traces may refer to a previously defined context (again optionally overriding its attributes) to describe a context change that persists only for the duration of that trace.

Although the use of the <context> element and attributes is strongly encouraged, default interpretations are provided so that they are not required in an InkML file if all trace data is recorded in the same virtual coordinate system, and its relationship to device coordinates is either not needed or unknown.

Attributes:

Contents:

The <context> element consolidates all salient characteristics of one or more ink traces. It may be specified by declaring all non-default attributes, or by referring to a previously defined context and overriding specific attributes. The element is found either in the <definitions> element or as a child of the <ink> element in Streaming InkML

4.2 Ink Sources

4.2.1 <inkSource> element

Attributes:

Contents:

Examples:

<inkSource xml:id="mytablet"
   manufacturer="Example.com"
   model="ExampleTab 2000 USB"
   specificationRef="http://www.example.com/products/exampletab/2000usb.html">

   <traceFormat>
      <channel name="X" ... />
      <channel name="Y" ... />
      <channel name="F" ... />
   </traceFormat>
   <sampleRate uniform="true" value="200"/>
   <latency value="50"/>
   <activeArea size="A6" height="100" width="130" units="mm"/>
   <sourceProperty name="weight" value="100" units="g"/>

   <channelProperties>
      <channelProperty channel="X" name="resolution" value="5000" units="1/in"/>
      <channelProperty channel="Y" name="resolution" value="5000" units="1/in"/>
      <channelProperty channel="Y" name="peakRate"   value="50"   units="cm/s"/>
      <channelProperty channel="F" name="resolution" value="1024" units="dev"/>
   </channelProperties>

</inkSource>

The <inkSource> element will allow specification of:

<sampleRate uniform="true" value="200"/>

<latency value="50"/>

<activeArea size="A6" height="100" width="130" units="mm"/>

<sourceProperty name="weight" value="100" units="g"/>

<channelProperties>
   <channelProperty channel="X" name="resolution" value="5000" units="1/in"/>
   <channelProperty channel="Y" name="resolution" value="5000" units="1/in"/>
   <channelProperty channel="Y" name="peakRate"   value="50"   units="cm/s">
   <channelProperty channel="F" name="resolution" value="1024" units="dev"/>
</channelProperties>

<channelProperty channel="F" name="threshold" value="0.1" units="N"/>
<channelProperty channel="X" name="quantization" value="0.01" units="mm"/>

4.3 Brushes

Along with trace data, it is often necessary to record certain attributes of the pen during ink capture. For example, in a note taking application, it is important to be able to distinguish between traces captured while writing as opposed to those which represent erasures. Because these attributes will often be application specific, this specification does not attempt to enumerate all the brush attributes which can be associated with a trace. It provides a syntax for specifying brush property names, units and values.  Some common brush property names are defined by the specification.  But applications may define other named properties not explicitly named in the specification since it is possible to imagine attributes which are described using complex functions parameterized by time, pen-tip force, or other factors. The specification allows for capturing the fact that a given trace was recorded in a particular brush context, leaving the details of precisely defining specific attributes of that context (such as complex brush geometries and colors in non-RGB color spaces) to a higher-level, application specific layer.

Depending on the application, brush attributes may change frequently. Accordingly, there should be a concise mechanism to assign the attributes for an individual trace. On the other hand, it is likely that many traces will be recorded using the same sets of attributes; therefore, it should not be necessary to explicitly state the attributes of every trace (again, for reasons of conciseness). Furthermore, it should be possible to define entities which encompass these attribute sets and refer to them rather than listing the entire set each time. Since many attribute sets will be similar to one another, it should also be possible to inherit attributes from a prior set while overriding some of the attributes in the set.

4.3.1 <brush> element

Attributes:

Contents:

In the ink markup, brush attributes are described by the <brush> element. This element allows for the definition of reusable sets of brush attributes which may be associated with traces. For reference purposes, a brush specifies an identifier which can be used to refer to the brush. A brush can inherit the attributes of another <brush> element by including a brushRef attribute which contains the id of the referenced brush. The brush attributes are stored in <brushProperty> child elements. Brushes may be used to convey information about how a stroke is to be rendered or simply to distinguish between different types of traces (e.g. an eraser vs. a pen, different writers). In this later case, all that matters is that brushes are distinct so no brush properties are necessary.

Brush attributes are associated with traces using the brushRef attribute. When it appears as an attribute of an individual <trace>, the brushRef specifies the brush attributes for that trace. When it appears as an attribute of a <traceGroup> element, the brushRef specifies the common brush attributes for all traces enclosed in the <traceGroup>. Within the <traceGroup>, an individual trace may still override the traceGroup's brush attributes using a brushRef attribute.

Brush attributes can also be associated with a context by including the brushRef attribute on a <context> element. Any traces which reference the context using a contextRef attribute are assigned the brush attributes defined by the context. If a trace includes both brushRef and contextRef attributes, the brushRef overrides any brush attributes given by the contextRef.

The default brush may be explicitly specified using the URI "#DefaultBrush".  The id "DefaultBrush" is therefore reserved and may not be used as the id of a user defined <brush> element.  The default brush is identical to a user defined brush that has not explicit <brushProperty> child elements.

In streaming ink markup, brushes are assigned to a trace according to the current brush, which can be set using the <context> and <brush> elements. See section Streaming Applications for a detailed description of streaming mode.

4.3.2 <brushProperty> element

The <brushProperty> element provides a mechanism for the storage of named properties of brushes. The following brush property names, with their specified meanings, are reserved. Other properties may be defined by the user.

Property name	Interpretation
width	Width of the brush. If the width property is not given and a BW channel is present, the values of the BW channel are used as the brush width. The default value is defined by the application.
height	Height of the brush. If a height property is not given and a BH channel is present, the values of the BH channel are used as the brush height. The default value is defined by the application.
color	Color of brush as three octets for RGB. If a color property is not given and color channels are present (C or CR, CG, CB or CC, CM, CY, CK), their values are used for the color. Default is #000000.
transparency	Transparency of brush as an integer: 0 is opaque. If a transparency property is not given and the transparency channel (A) is present, its value is used. Default is 0.
tip	The type of pen tip: ellipse, rectangle, or drop. If ellipse, then the width property specifies the horizontal diameter, and the height property specifies the vertical diameter.  If the height property is absent, its default value is the value of width. If rectangle, the width and height properties specify the width and height of the rectangle.  If the height property is absent, the default value is the value of width making the brush a square. If drop, the shape is defined by a circle and  two tangent lines to a point outside the circle, located above the circle on the vertical axis, as shown in Figure 4. The width property is the diameter the circle part, and the height property is the maximum diameter of the shape. Default is ellipse. If the OR channel is present, the tip shape is rotated counter-clockwise by this amount about its origin.
rasterOp	A value that defines how the colors of the pen and background interact.  In the example images below, the original background is white with the black text 'abc' and it is overwritten with a single curved yellow ink stroke. noOperation specifies no operation; the background is rendered without ink. copyPen specifies that the current pen color property is used and overwrites the background. maskPen specifies a combination of the colors common to both the pen and the display.  This value simulates the effect of a highlighter pen. The default value is copyPen, which indicates that the current pen color is used.  Applications may define additional rasterOp values.
antiAliased	The drawn ink is anti-aliased. Default is true.
fitToCurve	The ink is rendered as a series of curves versus as lines between pen sample points. Default is false.
ignorePressure	If true, pressure from the pen tip is ignored and the width of the ink remains the same regardless of the pressure of the pen on the tablet surface. If false, the width of the ink gets wider with increased pressure of the pen on the tablet surface. Default is false.

Figure 4.  Drop tip shape

Attributes:

Contents:

Example:

<brushProperty name="width" value="2" units="cm"/>
<brushProperty name="color" value="#FF0000"/>

4.4 Timestamps

Timestamping of traces is supported by the <timestamp> element and the timestampRef, timeOffset and duration attributes of the <trace> element. For ease of processing, all timestamps are expressed in milliseconds. Finer-grained timestamps are obtained using fractional values.

4.4.1 <timestamp> element

Attributes:

Contents:

The <timestamp> element establishes a reference timestamp which can then be used for relative timestamping of traces.

At most one of the attributes time, timestampRef or timeString is used. The time thus given, plus the value of the attribute timeOffset, gives the time value of the timestamp.

If more than one of time, timeString and timestampRef are given, then time is used if present. Failing that, timeString is used.

If none of time, timestampRef or timeString are given, then the timestamp refers to some unspecified moment in time. This is useful when the timestamp is referenced by multiple elements to provide relative timing information.

The four examples below illustrate the establishment of various reference timestamps. The first <timestamp> element, ts001, refers to January 2, 2004 at 7:00am, UTC. The second establishes timestamp ts002 which refers to January 2, 2004 at 7:10am, UTC (10 minutes after the reference timestamp ts001), and the third time stamp, ts003, gives the same time using the timeString attribute. The fourth creates ts004 with time January 2, 2004 at 7:10:04.32, UTC (4.32 seconds after the timestamp of trace ts002).

<timestamp xml:id="ts001" time="1073026800000"/>
<timestamp xml:id="ts002" timeOffset="600000" timestampRef="#ts001"/>
<timestamp xml:id="ts003" timeString="2004-01-02T07:10:00Z"/>
<timestamp xml:id="ts004" timeOffset="4320" timestampRef="#ts002"/>

4.6 Context Priority

To describe how contextual information is determined, we start with the notions of "fully resolved context" and "current context" as follows.

A fully resolved context is one for which all the context information (brush, canvas, canvasTransform, inkSource, timestamp, traceFormat) has been obtained either from direct children, by references or inherited. Values are obtained for the context information by giving the contents of the <context> priority over specific references (brushRef, canvasRef, canvasTransformRef, inkSourceRef, timestampRef, traceFormatRef), which take priority over contextRef, which takes priority over the current context.

The current context is a syntactic notion associated to each node in an ink document. Roughly speaking, the current context is changed only by <context>elements that occur directly as children to the <ink> element (i.e. not inside <definitions>). It is defined as follows.

• The first top-level child of an <ink> element has the default context its current context.
• If a top-level child of an <ink> element has a <context> element as its previous sibling, then that context fully resolved is the child's current context.
• If a top-level child has another kind of previous sibling, then that sibling's current context is the child's current context.
• All descendants of a <definitions> element have the default context as their current context.
• All descendants of other kinds of top-level children have that child's current context as their current context.
• All descendants of a top-level child have that child's current context as their current context.

The current context is central to streaming ink applications (see Streaming).

We can now describe how contextual information is determined for ink traces.

• For a top-level <trace>, <traceGroup> or <traceView> element (i.e. on that occurs as a direct child of an <ink> element), a specific reference (brushRef) takes priority over contextRef which takes priority over the current context. The resulting anonymous context is the context of this node.
• For other <trace>, <traceGroup> or <traceView> elements, a specific reference (brushRef) takes priority over contextRef which takes priority over the enclosing <traceGroup> or <traceView> node's context which takes priority over the current context. The resulting anonymous context is the context of this node.

5 Canvases

5.1 <canvas> element

The <canvas> element provides the virtual coordinate system, which uniquely identifies a shared virtual space for cooperation of ink applications. Together with the trace-to-canvas coordinate transform (discussed below), it provides a common frame of reference for ink collected in multiple sessions on different devices.

Attributes:

Contents:

<canvas xml:id="A4PaperCanvas">
   <traceFormat>
      <channel name="X" type="decimal" min="0" max="210" units="mm"/>
      <channel name="Y" type="decimal" min="0" max="297" units="mm"/>
   </traceFormat>
</canvas>

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

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

6 Generics

This section describes components of the ink markup which are applicable to multiple aspects of the ink markup.

6.1 Mappings

The <mapping> element provides a uniform syntax for the various uses of mappings in the ink markup. The element has an id attribute, which allows a particular mapping to be applied in multiple places. When a previously defined mapping is reused, the mappingRef attribute is used to refer to the <mapping> element, which might be defined in a <definitions> block. Mappings appear in the following different places in InkML:

1. In a <channel> element of a <traceFormat>, the <mapping> element is used to describe the transformation from the values actually produced by the device to the values recorded in the trace data.
2. Used by a <canvasTransform>, a mapping may be used to specify the forward or inverse transformations between an ink source and a canvas coordinate system.

InkML supports several types of mappings: unknown, identity, lookup table, affine map, formula (specified using a subset of MathML [MATHML2]) and cross product. The mapping type is indicated by the type attribute of a <mapping> element. Note: If no mapping appears for a <channel>, it defaults to "unknown", which is safer than assuming that 'X' is identical to the device's 'X' since some filtering or modifications could have been applied. Furthermore, one can specify whether the results of a mapping expression are absolute or relative to the current data value. This is done by means of the apply attribute. For lookup table mappings in particular, one can determine how to interpret intermediate mapping values. This is specified using the interpolation attribute.

Some points may have channel values that cannot be mapped.  These may lie outside the domain of a MathML mapping (e.g. division by zero, arcsine of 7) or outside the scope of a lookup table (e.g. below the lowest value when the interpolation scheme is other than "ceiling"). In this situation the behavior is not specified and may vary from implementation to implementation.  For example, an implementation may choose to raise an error or omit the points.

6.1.1 <mapping> element

Attributes

Contents

(The mathml prefix above is declared as "http://www.w3.org/1998/Math/MathML", the MathML schema namespace [MATHML2].)

<mapping xml:id="m01" type="identity" />

<channel name="X" type="decimal" units="pt" default="0">
   <mapping type="identity"/>   
</channel>

<mapping type="product">
   <mapping type="mathml">
      <bind target="X"/>
      <bind source="VR"  variable="r"/>
      <bind source="VTh" variable="theta"/>
      <math xmlns="http://www.w3.org/1998/Math/MathML">
         <apply>
            <times/>
            <ci>r</ci>
            <apply> <cos/> <ci>theta</ci> </apply>
         </apply>
      </math>
   </mapping>
   <mapping type="mathml">
      <bind target="Y"/>
      <bind source="VR"  variable="r"/>
      <bind source="VTh" variable="theta"/>
      <math xmlns="http://www.w3.org/1998/Math/MathML">
         <apply>
            <times/>
            <ci>r</ci>
            <apply> <sin/> <ci>theta</ci> </apply>
         </apply>
      </math>
   </mapping>
</mapping>

6.1.2 <bind> element

Attributes

Contents

The <bind> element is provided for binding channels to entities (variable names, lookup table columns) within a mapping, and thus it supports the reuse of predefined mappings. For each type of mapping, the relevant bindings can be expressed by the combined usage of the <bind> element's attributes, which are source, target, column and variable.

For an identity mapping (type="identity"), if the source channel has a different name than the channel being defined, this can be specified using a <bind> element with a source attribute. In the following markup, the <traceFormat> channel X contains unmanipulated data from the device's devX channel.   When the mapping type is an identity mapping, the <bind> element source attribute is required, and the other attributes target, column, and variable must not be present.

<channel name="X">
   <mapping type="identity">
      <bind source="devX"/>
   </mapping>
</channel>

Within a mapping formula (type="mathml"), the variable names in the formula need to be bound to particular channel names. This is specified using a combination of source and variable attributes for binding inputs of the formula, and target and variable for the output of the formula. This is useful if the same mapping formula is to be reused across multiple channels, like X and Y for example.  When the mapping type is an mathml mapping the column attribute for the <bind> element must not be present.

<mapping xml:id="m06" type="mathml">
   <bind target="X" variable="Q" />
   <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply>
         <plus/>
         <ci>Q</ci>
         <cn>10</cn>
      </apply>
   </math>
</mapping>

The example shown above means that the channel X is referred to by the variable name Q in the mapping expression "Q+10".

For a lookup table (type="table"), each index column must be bound to the channel that provides the input for the lookup operation. This is done with a <bind> element that specifies source and column attributes. Similarly, each value column must be bound to the channel that receives the output of the lookup. Its <bind> element specifies target and column.   When the mapping type is a lookup mapping the variable attribute for the <bind> element must not be present.

<mapping xml:id="m07" type="table">
   <bind target="X" column="1"/>
   <bind source="OTx" column="2"/>
   <bind source="P" column="3"/>
   <table apply="relative" interpolation="floor">
      10    45    512,
      9     45    400,
      8     45    372,
      7     45    418,

      10    50    510,
      9     50    403,
      8     50    302,
      7     50    407,

      10    55    512,
      9     55    410,
      8     55    303,
      7     55    405,

      10    60    512,
      9     60    420,
      8     60    355,
      7     60    401,
   </table>
</mapping>

<channel name="X"...>
   ...
   <mapping xml:id="m03" type="table">
      <bind source="OE"/>
      <bind target="X"/>
      <table apply="relative" interpolation="floor">
         45  10,
         50   9,
         55   8,
         60   7
      </table>
   </mapping>
   ...
</channel>

X += 10  if 45 ≤ OE < 50,
X += 9   if 50 ≤ OE < 55,
...

X += 10  if 45   ≤ OE < 47.5,
X += 9   if 47.5 ≤ OE < 52.5,
...

X += 10  if      OE ≤ 45,
X += 9   if 45 < OE ≤ 50,
...

 <mapping xml:id="m01" type="affine">
   <bind source="X" column="1"/>
   <bind source="Y" column="2"/>
   <affine>
      0 -1   0,
      1  0 200,
   </affine>
</mapping>

6.2 Definitions

6.2.1 <definitions> element

Attributes:

Contents:

<ink xmlns="http://www.w3.org/2003/InkML">
   <definitions>
      <brush xml:id="redPen"/>
      <brush xml:id="bluePen"/>
      <traceFormat xml:id="normal"/>
      <traceFormat xml:id="noForce"/>
      <context xml:id="context1"
            brushRef="#redPen"
            traceFormatRef="#normal"/>
      <context xml:id="context2"
            contextRef="#context1"
            brushRef="#bluePen"/>
   </definitions>
   <context contextRef="#context2" traceFormatRef="#noForce"/>
   <context xml:id="context3"/>
</ink>

<ink xmlns="http://www.w3.org/2003/InkML"
     xmlns:dc="http://dublincore.org/documents/2001/10/26/dcmi-namespace/">
   <annotation type="description">A Sample of Einstein's Writings</annotation>
   <annotation type="writer">Albert Einstein</annotation>
   <annotation type="contentCategory">Text/en</annotation>
   <annotation type="language" encoding="ISO639">en</annotation>
   <annotation dc:language="en"/>

   <trace xml:id="trace1">
      ...
   </trace>
   <traceGroup xml:id="tg1">
      <annotation type="truth">Hello World</annotation>
      <traceGroup>
         <annotation type="truth">Hello</annotation>
         <trace> ...  </trace>
         ...
      </traceGroup>
      <traceGroup>
         <annotation type="truth">World</annotation>
         <trace> ...  </trace>
         ...
     </traceGroup>
   </traceGroup>
   <traceView traceDataRef="#tg1"/>
</ink>

<ink xmlns="http://www.w3.org/2003/InkML">
   <annotation type="description">A Sample of Einstein's Writings</annotation>    
   <annotationXML type="metadata" encoding="rdf">
      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
               xmlns:dc="http://purl.org/dc/elements/1.1/" >
         <rdf:Description about=""
            dc:language="en"
            dc:date="2004-04-11"
            dc:creator="InkML Maker v0.1"
            dc:publisher="Famous Handwritings Ltd."/>
      </rdf:RDF>
   </annotationXML>

   <trace> ... </trace>
   ...
   <trace> ... </trace>
</ink>

<ink xmlns="http://www.w3.org/2003/InkML">
   <annotationXML type="truth" encoding="application/xhtml+xml">
      <html xmlns="http://www.w3.org/1999/xhtml">
         <body>
            <div xml:id="Ch1">
               <h1 xml:id="T1"><span xml:id="W1">Weather </span></h1>
               <p xml:id="P1">
                 <span xml:id="W2">The</span>
                 <span xml:id="W3">rain</span>
                 ... more words
               </p>
               <p xml:id="P2">...</p>
               ... more paragraphs
            </div>
            ... more chapters
         </body>
      </html>
   </annotationXML>

   <traceGroup>
      <annotationXML href="#Ch1"/>
      <traceGroup>
         <annotationXML href="#T1"/>
         <traceGroup>
            <!-- Weather -->
            <annotationXML href="#W1"/>
            <trace>...</trace>
         </traceGroup>
      </traceGroup>

      <traceGroup>
         <annotationXML href="#P1"/>
         <traceGroup>
            <!-- The -->
            <annotationXML href="#W2"/>
            <trace>...</trace>
         </traceGroup>
         <traceGroup>
            <!-- rain -->
            <annotationXML href="#W3"/>
            <trace>...</trace>
         </traceGroup>
         ... more words in paragraph
      </traceGroup>
   </traceGroup>
   <traceGroup>
       <annotationXML href="#P2"/>
       ... words in paragraph
   </traceGroup>
   ... more paragraphs in chapter.
</ink>

unitExpr ::=
      unit    
    | "1"      "/" unit
    | unitExpr "/" unit
    | unitExpr "*" unit

unitPrimitive ::= unit | "(" unitExpr ")"

unit ::= one of the units from the table above,
         with the exception of em, ex, % and dev.

7 Archives and Streams

The ink markup is expected to be used in many different scenarios. Ink markup data may be transmitted in substantially real time while exchanging ink messages, or ink documents may be archived for later retrieval or processing. InkML has been designed with both of these uses in mind, and it is natural to use InkML in a particular way in each of these settings.

These settings illustrate two different styles of ink generation and usage. In the later, the markup must facilitate the incremental transmission of a stream of ink data, while in the former, the markup should provide the structure necessary for operations such as search and interpretation. In order to support both cases, InkML provides archival and streaming modes of usage. These are not distinct and incompatible languages, but rather are two stylized ways of using InkML.

7.1 Archival Applications

Archival applications typically handle ink data that has been collected over some span of time and has some structure, organization or interpretation associated to the ink data. These applications may re-organize ink traces so it is preferable that the traces be state-free. That is, in archival applications, to the extent that ink traces make use of context information, this is always done explicitly and never through the "current" context.

In archival usage, contextual elements occur within one or more <definitions> elements and are assigned identifiers using the id attribute. References to defined elements are made using the corresponding brushRef, traceFormatRef, and contextRef attributes. This is illustrated in the following example:

<definitions>
   <brush xml:id="penA"/>
   <brush xml:id="penB"/>
   <traceFormat xml:id="fmt1">
      <channel name="X" type="integer"/>
      <channel name="Y" type="integer"/>
      <channel name="Z" type="integer"/>
   </traceFormat>

   <canvas xml:id="canvasA">
      <traceFormat>
         <channel name="X" type="decimal" min="0" max="200" units="mm"/>
         <channel name="Y" type="decimal" min="0" max="150" units="mm"/>
      </traceFormat>
   </canvas>
   <canvasTransform xml:id="trans1">
      <mapping type="affine">1 0 0 0,0 1 0 0</mapping>
   </canvasTransform>
   <canvasTransform xml:id="trans2">
      <mapping type="affine">2 0 0 0,0 -2 0 0</mapping>
   </canvasTransform>

   <context xml:id="context1"
      canvasRef="#canvasA"
      canvasTransformRef="#trans1"
      traceFormatRef="#fmt1"
      brushRef="#penA"/>

   <context xml:id="context2"
      canvasRef="#canvasA"
      canvasTransformRef="#trans2"
      traceFormatRef="#fmt1"
      brushRef="#penB"/>
</definitions>

This example defines two brushes ("penA" and "penB"), a traceFormat ("fmt1"), and two contexts ("context1" and "context2") which both refer to the same canvas ("canvasA") and traceFormat ("fmt1"), but with different canvas transforms and brushes. Note the use of the brushRef, traceFormatRef, canvasRef and canvasTransformRef attributes to refer to previously defined <brush>, <traceFormat> <canvas> and <canvasTransform> elements.

Within the scope of a <definitions> element, unspecified attributes of a <context> element are assumed to have their default values. The <definitions> block below defines "context1", which is comprised of "canvasA" with the default canvasTransform and traceFormat (the identity mapping and a traceFormat consisting of decimal X-Y coordinate pairs), and "penA".

 <definitions>
    <brush xml:id="penA"/>
    <context xml:id="context1"
      canvasRef="#canvasA"
      brushRef="#penA"/>
</definitions>

A <context> element can inherit and override the values of a previously defined context by including a contextRef attribute, so the following block defines "context2" which shares the same canvas ("canvasA") and traceFormat (the default format) as "context1", but has a different canvasTransform and brush.

<definitions>
   <brush xml:id="penA"/>
   <context xml:id="context1"
      canvasRef="#canvasA"  
      canvasTransformRef="#trans1"/>
   <context xml:id="context2"
      contextRef="#context1"
      canvasTransformRef="#trans2"
      brushRef="#penA"/>
</definitions>

Within archival ink markup, traces can either explicitly specify their context through the use of contextRef and brushRef attributes, or they can have their context provided by an enclosing traceGroup. In the following example, traces "t001" and "t003" have the context defined by "context1", while trace "t002" has a context consisting of the default canvas, canvasTransform and traceFormat, and "penA".

<trace xml:id="t001" contextRef="#context1">...</trace>
<trace xml:id="t002" brushRef="#penA">...</trace>

<traceGroup contextRef="#context1">
   <trace xml:id="t003">...</trace>
</traceGroup>

Traces within a <traceGroup> element can also override the context or brush specified by the traceGroup. In the following example, traces "t001" and "t003" have their context specified by "context1" while trace "t002" overrides the default brush of "context1" with "penA".

<traceGroup contextRef="#context1">
   <trace xml:id="t001">...</trace>
   <trace xml:id="t002" brushRef="#penA">...</trace>
   <trace xml:id="t003">...</trace>
</traceGroup>

A trace or traceGroup can both reference a context and override its brush, as in the following example which assigns the context specified by "context1" to traces "t001" and "t002", but with "penA" instead of the default brush.

<trace xml:id="t001" contextRef="#context1" brushRef="#penA">...</trace>
<traceGroup contextRef="#context1" brushRef="#penA">
    <trace xml:id="t002">...</trace>
</traceGroup> 

In archival mode, the ink markup processor can straightforwardly determine the context for a given trace by examining only the <definitions> blocks within the markup and the enclosing traceGroup for the trace.

7.2 Streaming Applications

Streaming ink applications present digital ink traces in sequential time order. Contextual information is inserted into the stream of ink traces, as needed, to provide interpretation for the ink strokes. These changes to the current trace context are given by <context> elements. These may directly contain brush, trace format and other information or which may refer to previously seen such elements. This corresponds to an event-driven model of ink generation, where events which result in contextual changes map directly to elements in the markup.

The current context consists of the set of canvas, canvasTransform, traceFormat and brush which are associated with subsequent traces in the ink markup. Initially, the current context contains the default canvas, an identity canvasTransform, the default traceFormat, and a brush with no attributes. Each <brush>, <traceFormat>, and <context> element which appears outside of a <definitions> element changes the current context accordingly (elements appearing within a <definitions> block have no effect on the current context, and behave as described above in the archival section).

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.

Outside of a <definitions> block, any values which are not specified within a <context> element are taken from the current context. For instance, the <context> element in the following example changes the current brush from "penB" to "penA", leaving the canvas, canvasTransform, and traceFormat unchanged from trace "t001" to trace "t002". That is, each context element is taken to inherit from the previously established context.

<brush xml:id="penA"/>
<brush xml:id="penB"/>
<trace xml:id="t001">...</trace>
<context brushRef="#penA"/>
<trace xml:id="t002">...</trace>

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.

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 (as shown above for the brushes "penA" and "penB"). This example:

<context xml:id="context1"
    canvasRef="#canvasA"
    canvasTransformRef="#trans1"
    traceFormatRef="#fmt1"
    brushRef="#penA"/>

defines a context which can be referred to by its identifier "context1". It also sets the current context to the values specified in the <context> element.

A previously defined context is referenced using the contextRef attribute of the <context> element. For example:

<context contextRef="#context1"/>

sets the current context to have the values specified by "context1". 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"/>

sets the current context to the values specified by "context1", except that the current brush is set to "penB" instead of "penA".

A <context> element which inherits and overrides values from a previous context can itself be reused, so the element:

<context xml:id="context2" contextRef="#context1" brushRef="#penB"/>

defines "context2" which has the same context values as "context1" except for the brush.

Finally, a <context> element with only an id has the effect of taking a "snapshot" of the current context which can then be reused. The element:

<context xml:id="context3"/>

defines "context3", whose values consist of the current canvasRef, canvasTransform, traceFormat, and brush at the point where the element occurs (note that since "context3" does not specify any values, the element has no effect on the current context).

An advantage of the streaming style is that it is easier to express overlapping changes to the individual elements of the context. However, determining the context for a particular trace can require more computation from the ink markup processor, since the entire file may need to be scanned from the beginning in order to establish the current context at the point of the <trace> element.

While it is possible to wait and generate each trace as it is completed, this can lead to considerable latency from the starting time with long strokes.  This may be avoided by generating traces of partial strokes and using continuation traces.

Finally, it should be noted that traces can overlap in time.  This can occur in collaborative applications with several writers or with one user on "multi-touch" devices.  Here it is also possible to generate traces for complete strokes on pen up, but applications may use partial strokes of limited time duration to guarantee that a buffer restricted to a sliding time window sees all simultaneous traces.

7.3 Archival and Streaming Equivalence

The following examples of archival and streaming ink markup data are equivalent, but they highlight the differences between the two styles:

Archival

<ink xmlns="http://www.w3.org/2003/InkML">
   ...
   <definitions>
      <brush xml:id="penA"/>
      <brush xml:id="penB"/>
      <context xml:id="context1"
         canvasRef="#canvas1"
         canvasTransformRef="#trans1"
         traceFormatRef="#format1"/>
      <context xml:id="context2"
         contextRef="#context1"
         canvasTransformRef="#trans2"/>
   </definitions>
   <traceGroup contextRef="#context1">
        <trace>...</trace>
        ...
   </traceGroup>
   <traceGroup contextRef="#context2">
        <trace>...</trace>
        ...
   </traceGroup>
   <traceGroup contextRef="#context2" brushRef="#penB">
        <trace>...</trace>
        ...
   </traceGroup>
   <traceGroup contextRef="#context1" brushRef="#penB">
        <trace>...</trace>
        ...
   </traceGroup>
   <traceGroup contextRef="#context1" brushRef="#penA">
        <trace>...</trace>
        ...
   </traceGroup>
</ink>

Streaming

<ink xmlns="http://www.w3.org/2003/InkML">
   ...
   <definitions>
      <brush xml:id="penA"/>
      <brush xml:id="penB"/>
   </definitions>
   <context xml:id="context1"
      canvasRef="#canvas1"
      canvasTransformRef="#trans1"
      traceFormatRef="#format1"/>
   <trace>...</trace>
   ...
   <context xml:id="context2"
      contextRef="#context1"
      canvasTransformRef="#trans2"/>
   <trace>...</trace>
   ...
   <context brushRef="#penB"/>
   <trace>...</trace>
   ...
   <context contextRef="#context1"/>
   <trace>...</trace>
   ...
   <context brushRef="#penA"/>
   <trace>...</trace>
   ... 
</ink>

In the archival case, the context for each trace is simply determined by the <trace> element, its enclosing traceGroup, and contextual elements defined in the <definitions> block, while in the streaming case, the context for a trace can depend on the entire sequence of context changes up to the point of the <trace> element.

However, the streaming case more simply expresses the changes of context involving "penB", "context1", and "penA", whereas the archival case requires the restatement of the unchanged values in the successive traceGroups.

The two styles of ink markup are equally expressive, but impose different requirements on the ink markup processor and generator. Tools to translate from streaming to archival style might also be of use to applications which work on stored ink markup.

8. Conformance

The contents of this section are normative.

8.1 Conforming InkML Documents

A document is a Conforming InkML Document if it meets both the following conditions:

• It is a well-formed XML document [XML] conforming to Namespaces in XML [XMLNS].
• It adheres to the specification described in this document (InkML Specification) including the constraints expressed in the Schema (see Appendix E) and having an XML Prolog and root element as specified in Section 2.1.

The InkML specification and these conformance criteria provide no designated size limits on any aspect of InkML documents. There are no maximum values on the number of elements, the amount of character data, or the number of characters in attribute values.

Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI. The term URI has been retained in preference to IRI to avoid introducing new names for concepts such as "Base URI" that are defined or referenced across the whole family of XML specifications.

8.2 Using InkML with other Namespaces

The InkML namespace is intended to be used with other XML namespaces as per the Namespaces in XML Recommendation [XMLNS]. Future work by W3C is expected to address ways to specify conformance for documents involving multiple namespaces.

8.3 Conforming InkML Processors

An InkML processor is a program that can process and/or generate Conforming InkML documents.

In a Conforming InkML Processor, the XML parser MUST be able to parse and process all XML constructs defined by XML 1.1 [XML] and Namespaces in XML [XMLNS]. It is not required that a Conforming InkML Processor uses a validating XML parser.

A Conforming InkML Processor MUST correctly understand and apply the semantics of each markup element or attribute as described by this document.

There is, however, no conformance requirement with respect to performance characteristics of the InkML Processor. For instance, no statement is required regarding the accuracy, speed or other characteristics of output produced by the processor. No statement is made regarding the size of input that a InkML Processor is required to support.