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 usingleveraging this method of input. Handwriting is an 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 transducer device and a pen that allowdevice 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. For instance, inIn addition to the pen position over time, InkML allows recording of information about transducer 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 in manufacturers' documentation "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.

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

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 retrieve them using either the time of creation of the handwritten notes or the tags associated with keywords. The tags are typically text strings created using a handwriting recognition system.

• Electronic Form-Filling

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

• Pen Input and Multimodal Systems

  Robust and flexible user interfaces can be created that integrate the pen with other input modalities such as speech. Higher robustness is achievable because cross-modal redundancy can be used to compensate for imperfect recognition on each individual mode. Higher flexibility is possible because users can choose the most appropriate from among various modes for achieving a task or issuing commands. This choice might be based on user preferences, suitability for the task, or external conditions. For instance, when noise in the environment or privacy is a concern, the pen modality is preferred over voice.

1.2 Elements

The current InkML specification defines a set of primitive elements sufficient for all basic ink applications. Few semantics are attached to these elements. 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 -- e.g., the X and Y coordinates of the pen's position. A sequence of traces accumulates to meaningful units, such as characters, words or diagrams. The <traceFormat> element is used to define the format of data within a trace.

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

<ink>
   <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 signalrepresenting. 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 transducer device used to collect the ink (e.g., the sampling rate and resolution) ismay be specified with the <inkSourcecaptureDevice> element.

Ink traces can have certain attributes such as color and width, writer identification, pen modes (eraser vs 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 remote on-linebatch forms processing (e.g., where forms are filled on electronic tablet computers and processed remotely). In these applications, all primitive elements are an entire <ink> element is written prior to processing. For ease of implementation, it is recommended that, in archival mode, referenced elements be defined inside of a declaration block using the <definitions> element.

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

Traces are the basic element used to record the trajectory of the pen as thea pen as a 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 sourcecapture devices, 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 and 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. If no channels of a specific type exist, the corresponding parts may be omitted. 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.

3.1.2 <intermittentChannels> element

Attributes:

Contents:

The <intermittentChannels> lists those channels whose value may optionally be recorded for each sample point. As with the <regularChannels> element, t The order of the enclosed channel declarations gives the order of the intermittent channel data samples within traces having this format.

3.1.3 <channel> element

Attributes:

Contents:

Within a <regularChannels> or <intermittentChannels> element, cChannels are described using the <channel> element, with name, type, and default various attributes.

The required name attribute specifies the interpretation of the channel in the trace data. The following 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.4 Orientation Channels

The channels OTx, OTy, OA, OE and OR are defined for recording of 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 described in the Mappings section can be employed to specify an applied sine transformation.

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.

3.1.6 Width Channel

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. Otherwise, the value of the time channel for a given sample point is defined to be the timestamp of that point in the units and frame of reference specified by its corresponding <inkSourcecaptureDevice> description (more precisely, by the <traceFormat><channelDef> element for the channel).

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

The units attribute gives the units of the recorded time values, and the relativeTo attribute describes the frame of reference for those recorded values. The value of the relativeTo 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 <inkSourcecaptureDevice> 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, 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">
   <regularChannels>
   <channel name="X" type="decimal">
      <mapping type="identity"/>
   </channel>
   <channel name="Y" type="decimal">
      <mapping type="identity"/>
   </channel>
   </regularChannels>
   <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 ink markup file both defines the format and installs it as the current format for subsequent traces (except within a <definitions> block). 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 for all traces:

<traceFormat xml:id="DefaultTraceFormat">
   <regularChannels>
   <channel name="X" type="decimal"/>
   <channel name="Y" type="decimal"/>
   </regularChannels>
</traceFormat>

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

3.2 Traces

Contents:

trace ::=
     wsp* points wsp*

points ::=
     point | point wsp+ points

point ::=
     regularPart intermittentPart?

regularPart ::=
     regularValue+

intermittentPart ::=
     ":" wsp* intermittentValue* ";" wsp*

regularValue ::=
     qualifier? value wsp*

intermittentValue ::=
     value wsp*

value ::=
     "-"? (integer | decimal ) | "*" | "?"

integer ::=
     "-"? digit+

decimal ::=
          "-"? digit+ "." digit+ 

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

qualifier ::=
     "!" | "'" | """

wsp ::=
     #x20 | #x9 | #xD | #xA

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

point ::=
     value+

value ::=
     qualifier? "-"? decimal | hex | "T" | "F" | "*" | "?"

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

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

qualifier ::=
     "!" | "'" | """

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. A value of "continuation" means both that the pen contact state is retained from the previous trace element and that the points of the current trace element are a temporally contiguous continuation of (and thus should be connected to) the previous trace. This allows a trace to be spread across several elements for purposes such as streaming.

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.

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

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

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 andor 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 <traceFormat>. If any intermittent values are reported for the point, they are given next, in the order they are specified in the <traceFormat>. Unreported intermittent channels are interpreted as though they were given by the wildcard "*". If any intermittent values are reported for the point, the set of intermittent values is preceded by a colon and ended with a semicolon. Within these delimiters, the intermittent channels are represented in the order given by the <traceFormat>. The list may be terminated early with the semicolon, and the unreported intermittent channels are interpreted with wildcards.

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

<traceFormat>
   <regularChannels>
   <channel name="X" type="decimal"/>
   <channel name="Y" type="decimal"/>
   </regularChannels>
   <intermittentChannels>
      <channel name="B1" type="boolean" default="F"/>
      <channel name="B2" type="boolean" default="F"/>
   </intermittentChannels>
</traceFormat>

<trace 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 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 use of<traceGroup> is reserved forelement may be used for various purposes, such as the containment of traces according to their properties at the time of capture. The element may not be nested, and it is not meant to bemay be used as a generic grouping mechanism, e.g. for the semantic labelling of traces. For that purpose, InkML provides the <traceRef> element.

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

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

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

A number of details comprise the context in which ink is written and recorded. 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: canvas, canvasTransformRef, traceFormatRef, captureDeviceRef, and brushRef, and timestampRef. The context element both defines 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 ink markup file if all trace data is recorded in the same virtual coordinate system, and its relationship to digitizer coordinates is either not needed or unknown.

Attributes:

Contents:

<context id="context1" canvas="canvas1"
 traceFormatRef="format1" brushRef="brush1"/>
<context id="context2" contextRef="context1" 
 brushRef="brush2"/>
<context id="context3" canvas="canvas1"
 canvasTransform="2 0 0 0 2 0"
 traceFormatRef="format2" brushRef="brush3"/>

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

4.2.1 <inkSourcecaptureDevice> 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 href="#XYF"/>

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

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

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

</inkSource>

  

<captureDevice id="foo"
                manufacturer="AcmePen"
                model="FooBar 2000 USB"
                sampleRate="100"
                uniform="TRUE"
                latency="50">

   <channelList>
      ...

   </channelList>
</captureDevice>
  

The <inkSourcecaptureDevice> element will allow specification of:

The <inkSourcecaptureDevice> block, including <channelList>, will often be specified by reference to a separate xml document, either local or at some remote URI. Ideally, <inkSourcecaptureDevice> blocks for common devices will become publicly available.

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

<latency value="50"/>
  

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

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

<channelList id="foo">
   <channelDef name="X">
      ...

   </channelDef>
</channelList>

<channelDef name="S">
   <representation  type="boolean"/>
   <threshold       value="0.1" units="newtons"/>
   <skew          value="5" units="ms"/>
</channelDef>

<channelDef name="X">
   <representation  type="integer"/>
   <range           min="0" max="8191"/>
   <resolution    value="0.1"  units="mm"/>
   <quantization  value="0.01" units="mm"/>
   <noise         value="0.05" units="mm"/>
   <accuracy      value="0.5"  units="mm"/>
   <crossCoupling>
      <bind source="Tx"/>
      <bind source="Ty"/>
      <mapping type="mathml" apply="relative">
         <math>
         ...
         </math>
      </mapping>
   </crossCoupling>
   <skew          value="2" units="ms"/>
   <minBandwidth  value="15.0"/>
   <distortion    value=".001"/>

</channelDef>