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 .)  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 element. The fundamental data element in an InkML file is the . 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:

   
      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
   
   
      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
   
   
      227 50, 226 64, 225 78, 227 92, 228 106, 228 120, 229 134,
      230 148, 234 162, 235 176, 238 190, 241 204
   
   
      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
   
   
      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
   

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 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 element. Traces that share the same characteristics, such as being written with the same brush, can be grouped together with the 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 element is written prior to processing. For ease of implementation in archival mode, referenced elements should be defined inside a declaration block using the 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.

   ...

3 Traces and Trace Formatting

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 and elements. The element specifies the encoding format for each sample of a recorded trace, while elements are used to represent the actual trace data. If no 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 element

Attributes:

Contents:

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

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

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

Attributes:

Contents:

Channels are described using the 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 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 element (described in the Mappings section) within the element. If no mapping is specified for a channel, it is assumed to be unknown.

3.1.3 element

Attributes:

Contents:

The 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 section is optional and must appear after the regular elements (if any) within a 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 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 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 . In the case of the time channel, its 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.

If no 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 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"):

The appearance of a element in an InkML file both defines the format and installs it as the current format for subsequent traces except within a block (see Specifying Trace Formats). The id attribute of a allows the format to be reused by multiple contexts (see the Context section). If no is specified, the following default format is assumed:

Thus, in the simplest case, an InkML file may contain nothing but elements within an 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 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 element.

The type attribute of a 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.

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

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 elements of the applicable . 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 elements of the applicable . 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:

   
   

   
      
      
   



   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

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:

   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

3.3.1 element

Attributes:

Contents:

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

    ...
    ...

The 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 to traces in archival ink markup. For additional details about this usage, see the Archival Applications section.

   911 912, 921 922, 931 932

   
      111 112, 121 122
      
         221 212, 221 222
         311 312, 321 322
      
      411 412, 421 422
      
         
            521 512, 521 522
            611 612, 621 622
         
      
      711 712, 721 722
   

   
      
      
   

   

   921 922, 931 932

   
      
         221 212, 221 222
         311 312, 321 322
      
      411 412, 421 422
      
         
            521 512, 521 522
         
      
   

   931 932
   
      
         221 212, 221 222
         311 312
      
   

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 element which provides a means to associate a defined context with trace data.

4.1 The element

This section describes the 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 and 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 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 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 element or as a child of the element in Streaming InkML

4.2 Ink Sources

4.2.1 element

Attributes:

Contents:

Examples:

The element will allow specification of:

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 element

Attributes:

Contents:

In the ink markup, brush attributes are described by the 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 element by including a brushRef attribute which contains the id of the referenced brush. The brush attributes are stored in 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 , the brushRef specifies the brush attributes for that trace. When it appears as an attribute of a element, the brushRef specifies the common brush attributes for all traces enclosed in the . Within the , 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 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 element.  The default brush is identical to a user defined brush that has not explicit child elements.

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

4.3.2 element

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

4.4 Timestamps

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

4.4.1 element

Attributes:

Contents:

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

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 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 elements that occur directly as children to the element (i.e. not inside ). It is defined as follows.

• The first top-level child of an element has the default context its current context.
• If a top-level child of an element has a 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 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 , or element (i.e. on that occurs as a direct child of an 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 , or elements, a specific reference (brushRef) takes priority over contextRef which takes priority over the enclosing or node's context which takes priority over the current context. The resulting anonymous context is the context of this node.

5 Canvases

5.1 element

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

6 Generics

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

6.1 Mappings

The 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 element, which might be defined in a block. Mappings appear in the following different places in InkML:

1. In a element of a , the 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 , 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 element. Note: If no mapping appears for a , 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 element

Attributes

Contents

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

   
      
      
      
      $r\cos \mathrm{theta}$
   
   
      
      
      
      $r\sin \mathrm{theta}$
   

   
   $Q+10$

 
   
   
   
      0 -1   0,
      1  0 200,
   

   A Sample of Einstein's Writings
   Albert Einstein
   Text/en
   en
   

   
      ...
   
   
      Hello World
      
         Hello
          ...  
         ...
      
      
         World
          ...  
         ...