Movatterモバイル変換

1 Overview

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

A pen-based interface is enabled by a device that allowsmovements of the pen to be captured as digital ink. A number ofmethods may be used for ink capture, including those based on radiofrequency, optical tracking, physical pressure, or othertechnologies. Digital ink can be passed on to recognition softwarethat will convert the pen input into appropriate computer actions.Alternatively, the handwritten input can be organized into inkdocuments, notes or messages that can be stored for later retrievalor exchanged through telecommunications means. Such ink documentsare appealing because they capture information as the user composedit, including text in any mix of languages and drawings such asequations and graphs.

Hardware and software vendors have typically stored andrepresented digital ink using proprietary or restrictive formats.The lack of a public and comprehensive digital ink format hasseverely limited the capture, transmission, processing, andpresentation of digital ink across heterogeneous devices developedby multiple vendors. In response to this need, the Ink MarkupLanguage (InkML) provides a simple and platform-neutral data formatto promote the interchange of digital ink between softwareapplications.

InkML supports a complete and accurate representation of digitalink. In addition to the pen position over time, InkML allowsrecording of information about device characteristics and detaileddynamic behavior to support applications such as handwritingrecognition and authentication. For example, there is support torecord additional information such as pen tilt and pen tip force(often referred to as "pressure") and information about therecording device such as accuracy and dynamic distortion. InkMLalso provides features to support rendering of digital ink capturedoptically 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 storesemantic information, such as the plain text of ink recognized ashandwriting.  Nor is it a goal of InkML to store thecontextual information about the ink, such as what kind of field ina form where ink was written.  However, InkML provides meansfor extension.  InkML can include XML from other schemas atspecific locations in a file or stream (see<annotationXML>.) Additionally, InkML could be embedded within other XMLdocuments.

1.1 Uses of InkML

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

• Ink Messaging

  Two-way transmission of digital ink, possibly wireless, offersmobile-device users a compelling new way to communicate. Users candraw or write with a pen on the device's screen to compose a notein their own handwriting. Such an ink note can then be addressedand delivered to other mobile users, desktop users, or faxmachines. The recipient views the message as the sender composedit, 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. Theink annotation could be used for indexing the photo (for example,one could assign different handwritten glyphs to differentcategories of pictures).

• Ink Archiving and Retrieval

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

• Electronic Form-Filling

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

• Pen Input and Multimodal Systems

  Robust and flexible user interfaces can be created thatintegrate the pen with other input modalities such as speech.Multimodal applications may share context information acrossmodalities, leading to better recognition in each modalityindividually.  In this setting, pen input may be used todisambiguate voice recognition and vice-versa.

1.2 Elements

The current InkML specification defines a set of primitiveelements sufficient for all basic ink applications. All content ofan InkML document is contained within a single<ink> element. The fundamental data element inan InkML file is the<trace>. A trace representsa sequence of contiguous ink points, where each point captures thevalues of particular quantities such as the X and Y coordinates ofthe pen's position. A sequence of traces accumulates to meaningfulunits, such as characters, words or diagrams.

In its simplest form, an InkML file with its enclosed traceslooks 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 looklike this when rendered:

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

Information about the device used to collect the ink (e.g., thesampling 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 soon. These and other attributes are captured using the<brush> element. Traces that share the samecharacteristics, such as being written with the same brush, can begrouped together with the<traceGroup>element.

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

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

1.3 Exchange Modes

Most ink-related applications fall into two broad categories:"Streaming" and "Archival". Archival ink applications capture andstore digital ink for later processing, such as documentstorage/retrieval applications and batch forms processing . Inthese applications, an entire<ink> element iswritten prior to processing. For ease of implementation in archivalmode, referenced elements should be defined inside a declarationblock using the<definitions> element (seeThe Default Context section, theDefinitions section, and theArchival Applications section).

Streaming ink applications, on the other hand, transmit digitalink as it is captured, such as in the electronic whiteboard examplementioned above. In order to support a streaming style of inkmarkup generation, the InkML language supports the notion of a"current" state (e.g., the current brush) and allows forincremental 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 recordthe trajectory of a pen as the user writes digital ink. Morespecifically, these recordings describe sequences of connectedpoints. On most devices, these sequences of points will be boundedby pen contact change events (pen-up and pen-down), although somedevices may simply record proximity and force data withoutproviding an interpretation of pen-up or pen-down state.

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

These variations in the information available from different inksources, or needed by different applications, are supported inInkML through the<traceFormat> and<trace> elements. The<traceFormat> element specifies the encodingformat for each sample of a recorded trace, while<trace> elements are used to represent theactual trace data. If no<traceFormat> isspecified, a default encoding format of X followed by Y coordinatesis assumed.

Traces generated by different devices, or used in differingapplications, may contain different types of information. InkMLdefineschannels to describe thedata that may be encoded in a trace.

A channel can be characterized as eitherregular,meaning that its value is recorded for every sample point of thetrace, orintermittent, meaning that its value may changeinfrequently and thus will not necessarily be recorded for everysample point. X and Y coordinates are examples of likely regularchannels, while the state of a pen button is likely to be anintermittent channel.

3.1 Trace Formats

3.1.1<traceFormat>element

Attributes:

Contents:

The<traceFormat> element describes theformat used to encode points within<trace>elements. In particular, it defines the sequence of channel valuesthat occurs within<trace> elements. The orderof 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 orderedsequence of<channel>s, giving the regularchannels (if any), followed by an optional<intermittentChannels> section. The order of thecoordinates in each point of a trace is determined by the order ofthe<channel> elements in the trace format,including those from the intermittent channels part.

The<context> element may use thetraceFormatRef 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 theURI "#DefaultTraceFormat".

3.1.2<channel> element

Attributes:

Contents:

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

The requiredname attribute specifies the interpretationof the channel in the trace data. The following case sensitive channel names, withtheir specified meanings, are reserved:

Thetype attribute defines the encoding type for thechannel (either boolean, decimal, or integer). Iftype isnot specified, it defaults to decimal.

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

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

3.1.3<intermittentChannels> element

Attributes:

Contents:

The<intermittentChannels> elementlists those channels whose value may optionally be recorded foreach sample point.  The order of the enclosed channeldeclarations gives the order of the intermittent channel datasamples within traces having this format.  The<intermittentChannels> sectionis 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 orientationdata. Implementers may choose to use either pen azimuth OA and penelevation OE, or alternatively tilt angles OTx and OTy. The latterare the angles of projections of the pen axis onto the XZ and YZplanes, measured from the vertical. It is often useful to recordthe sine of this angle, rather than the angle itself, as this isusually more useful in calculations involving angles. The<mapping> element can beemployed to specify an applied sine transformation. While it is notforbidden to use channels from different groups together (i.e. frommore than one of {OA, OE} and {OTx, OTy}), applications will notnormally do this.

The third degree of freedom in orientation is generally definedas the rotation of the pen about its axis. This is potentiallyuseful (in combination with tilt) in application such asillustration or calligraphy, and signature verification.

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

Figure 2b explains the definition of the Tilt-X and the Tilt-Yangles. For both the origin is along the Z-axis. Tilt-X increasesup to +90 degrees for inclinations along the positive X-axis anddecreases up to -90 degrees for inclinations along the negativeX-axis. Respectively, Tilt-Y is defined for pen inclinations alongthe Y-axis.

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

Figure 3b shows the Rotation of the pen along its longitudinalaxis.  The departure of a reference mark or meridian on thepen barrel from the nominal 'up' direction which may be constructedby a ray perpendicular to the pen barrel (somewhere not at the tip)and intersecting a pure-Z ray arising from the surface of the penpassing through the tip. This angle is measured in a clockwisedirection when viewing the pen barrel from tail to tip, indegrees.

3.1.6 Width Channels

3.1.7 Time Channel

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

The time channel can be specified as either a regular orintermittent channel. When specified as a regular channel, thesingle quote prefix can be used to record incremental time betweensuccessive points.  Thevalue of the time channel for a given sample point is defined to bethe timestamp of that point in the units and frame of referencespecified by therespectTo attribute of the timechannel that is defined in the associated<traceFormat> of thetrace.

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 ofthe time channel, its<channel> element containsboth aunits andrespectTo attribute.

Theunits attribute gives the units of the recorded timevalues, and therespectTo attribute describes the frame ofreference for those recorded values. The value of therespectTo attribute is a reference to a time stamp. If it isnot given, the time channel values are relative to the beginningtimestamps of the individual traces in which they appear.

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

If no<traceFormat> information is provided, orif no value is specified for therespectTo attribute, theink processor cannot make any assumption about the relative timingof points within different traces. Likewise, if no units arespecified, no assumption can be made about the units of the timechannel data.

3.1.8 User Defined Channels

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

3.1.9 Specifying Trace Formats

The following example defines a<traceFormat> which reports decimal-valued X andY coordinates for each point, and intermittent boolean values forthe 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 bothdefines the format and installs it as the current format forsubsequent traces except within a<definitions> block (seeSpecifying Trace Formats). Theidattribute of a<traceFormat> allows the formatto be reused by multiple contexts (see theContext section). If no<traceFormat> is specified, the followingdefault 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 nothingbut<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 thedata captured by the digitizer. It contains a sequence of pointsencoded according to the specification given by the<traceFormat> element.

Thetype 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 isneither pen-up nor pen-down, and may be either unknown or variablewithin the trace. For example, a signature may be captured as asingle indeterminate trace containing both the actual writing andthe trajectory of the pen between strokes.  The values of the tip switch state channel "S", if present in the trace, overrides the value of thetype attribute.

If acontinuation attribute is present, itindicates that the current trace is a continuation trace, i.e. itspoints are a temporally contiguous continuation of (and thus shouldbe connected to) another trace element. The possible values of theattribute are:

• begin: the current trace is the first of the setof continuation traces
• end: the current trace is the last of the set ofcontinuation 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 thefirst trace in the set (i.e. thecontinuationattribute has valuemiddle orend) then apriorRef attribute must be present and must containthe URI of the trace of which the current trace is a continuation.Abegin ormiddle trace can be the priortrace for exactly one trace. Anend trace cannot bethe prior trace of any other trace.

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

A second difference encoding must be preceded by a singledifference representation; which, in turn, must be preceded with anexplicit encoding.

All traces must begin with an explicit value, not with a firstor second difference. This is true of continuation traces as well.This allows the location and velocity state information to bediscarded at the end of each trace, simplifying parserdesign.  This is true for continuation traces.

Both regular and intermittent channels may be encoded with thewildcard character "*". This wildcard character means either thatthe value of the channel remains at the previous channel value (ifexplicit), or that the channel continues integrating with theprevious 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 reportedfirst in the order given by the<channel>elements of the applicable<traceFormat>. Allregular channels must be reported, if only with the explicitwildcard "*".  If any intermittent values are reported for thepoint, they are given next, in the order given by the<intermittentChannels> elements of theapplicable<traceFormat>. Unreportedintermittent channels are interpreted as though they were given bythe wildcard "*".

Here is an example of a trace of 11 points, usingthe 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 whitespaceformatting for clarity. The following trace specification isidentical 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 groupsuccessive traces which share common characteristics, such as thesame<traceFormat>. The brush and contextsections describe other contextual values that can be specified fora<traceGroup>. In the following example the twotraces enclosed in the<traceGroup> share thesame brush (see theBrushes section for adescription of brushes).

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

The<traceGroup> element may be used forvarious purposes, such as to group traces according to theirproperties at the time of capture or according to computedrecognition results. The element may be nested, and it may be usedas a generic grouping mechanism, e.g. for the semantic labeling oftraces.

Trace groups are the primary mechanism for assigning<context> to traces in archival ink markup. Foradditional details about this usage, see theArchival 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 manydetails. Examples include the size of the surface the traces wererecorded on, the pen tip used or the accuracy of the pressuremeasurements. This contextual information needs to be captured byInkML in order to fully characterize the recorded ink data. Thissection defines markup that provides a way to describe thisinformation, including the<context> elementwhich provides a means to associate a defined context with tracedata.

4.1 The<context>element

This section describes the<context> elementand its attributes. The context element both provides access to auseful shared context (canvas) and serves as a convenientagglomeration of contextual attributes. It is used by the<traceGroup> and<traceView>elements to define the complete shared context of a group of tracesor may be referred to as part of a context change in streamingmode. In either mode, individual attributes may be overridden attime of use. Additionally, individual traces may refer to apreviously defined context (again optionally overriding itsattributes) to describe a context change that persists only for theduration of that trace.

Although the use of the<context> element andattributes is strongly encouraged, default interpretations areprovided so that they are not required in an InkML file if alltrace data is recorded in the same virtual coordinate system, andits relationship to device coordinates is either not needed orunknown.

Attributes:

Contents:

The<context> element consolidates allsalient characteristics of one or more ink traces. It may bespecified by declaring all non-default attributes, or by referringto 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 inStreaming 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 allowspecification 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 certainattributes of the pen during ink capture. For example, in a notetaking application, it is important to be able to distinguishbetween traces captured while writing as opposed to those whichrepresent erasures. Because these attributes will often beapplication specific, this specification does not attempt toenumerate all the brush attributes which can be associated with atrace. It provides a syntax for specifying brush property names,units and values.  Some common brush property names aredefined by the specification.  But applications may defineother named properties not explicitly named in the specificationsince it is possible to imagine attributes which are describedusing complex functions parameterized by time, pen-tip force, orother factors. The specification allows for capturing the fact thata given trace was recorded in a particular brush context, leavingthe details of precisely defining specific attributes of thatcontext (such as complex brush geometries and colors in non-RGBcolor spaces) to a higher-level, application specific layer.

Depending on the application, brush attributes may changefrequently. Accordingly, there should be a concise mechanism toassign the attributes for an individual trace. On the other hand,it is likely that many traces will be recorded using the same setsof attributes; therefore, it should not be necessary to explicitlystate the attributes of every trace (again, for reasons ofconciseness). Furthermore, it should be possible to define entitieswhich encompass these attribute sets and refer to them rather thanlisting the entire set each time. Since many attribute sets will besimilar to one another, it should also be possible to inheritattributes from a prior set while overriding some of the attributesin 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 thedefinition of reusable sets of brush attributes which may beassociated with traces. For reference purposes, a brush specifiesan identifier which can be used to refer to the brush. A brush caninherit the attributes of another<brush>element by including a brushRef attribute which contains the id ofthe referenced brush. The brush attributes are stored in<brushProperty> child elements. Brushes may beused to convey information about how a stroke is to be rendered orsimply to distinguish between different types of traces (e.g. aneraser vs. a pen, different writers). In this later case, all thatmatters is that brushes are distinct so no brush properties arenecessary.

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

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

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 traceaccording to the current brush, which can be set using the<context> and<brush>elements. See sectionStreamingApplications for a detailed description of streaming mode.

4.3.2<brushProperty> element

The<brushProperty> element provides amechanism for the storage of named properties of brushes. Thefollowing brush property names, with their specified meanings, arereserved. 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, thevalues 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 forRGB. If a color property is not given and color channels are present (Cor CR, CG, CB or CC, CM, CY, CK), their values are used for thecolor. Default is #000000.
transparency	Transparency of brush as an integer: 0is opaque. If a transparency property is not given and the transparencychannel (A) is present, its value is used. Default is 0.
tip	The type of pen tip:ellipse,rectangle, ordrop. Ifellipse, then the width property specifies thehorizontal diameter, and the height property specifies the verticaldiameter.  If the height property is absent, its default valueis the value of width. Ifrectangle, the width and height propertiesspecify the width and height of the rectangle.  If the heightproperty is absent, the default value is the value of width makingthe brush a square. Ifdrop, the shape is defined by a circleand  two tangent lines to a point outside the circle, locatedabove the circle on the vertical axis, as shown inFigure 4. The width property is thediameter the circle part, and the height property is the maximumdiameter of the shape. Default isellipse. If the OR channel is present, the tip shape is rotatedcounter-clockwise by this amount about its origin.
rasterOp	A value that defines how the colors ofthe pen and background interact.  In the example images below,the original background is white with the black text 'abc' and itis overwritten with a single curved yellow ink stroke. noOperation specifies nooperation; the background is rendered without ink. copyPen specifies that thecurrent pen color property is used and overwrites thebackground. maskPen specifies a combinationof the colors common to both the pen and the display.  Thisvalue simulates the effect of a highlighter pen. The default value iscopyPen, which indicates thatthe current pen color is used.  Applications may defineadditional rasterOp values.
antiAliased	The drawn ink is anti-aliased. Default is true.
fitToCurve	The ink is rendered as a series of curves versus aslines between pen sample points. Default is false.
ignorePressure	If true, pressure from the pen tip is ignored andthe width of the ink remains the same regardless of the pressure ofthe pen on the tablet surface. If false, the width of the ink gets wider with increased pressureof 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 thetimestampRef,timeOffset andduration attributes of the<trace> element. For ease of processing, alltimestamps are expressed in milliseconds. Finer-grained timestampsare obtained using fractional values.

4.4.1<timestamp>element

Attributes:

Contents:

The<timestamp> element establishes areference timestamp which can then be used for relativetimestamping of traces.

At most one of the attributestime,timestampRefortimeString is used. The time thus given, plus the valueof the attributetimeOffset, gives the time value of thetimestamp.

If more than one oftime,timeString andtimestampRef are given, thentime is used if present.Failing that,timeString is used.

If none oftime,timestampRef ortimeStringare given, then the timestamp refers to some unspecified moment intime. This is useful when the timestamp is referenced by multipleelements to provide relative timing information.

The four examples below illustrate the establishment of variousreference timestamps. The first<timestamp>element, ts001, refers to January 2, 2004 at 7:00am, UTC. Thesecond establishes timestamp ts002 which refers to January 2, 2004at 7:10am, UTC (10 minutes after the reference timestamp ts001),and the third time stamp, ts003, gives the same time using thetimeString attribute. The fourth creates ts004 with timeJanuary 2, 2004 at 7:10:04.32, UTC (4.32 seconds after thetimestamp 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 startwith the notions of "fully resolved context" and "current context"as follows.

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

Thecurrent context is a syntactic notion associated toeach node in an ink document. Roughly speaking, the current contextis changed only by<context>elements that occurdirectly as children to the<ink> element (i.e.not inside<definitions>). It is defined asfollows.

• 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 hasa<context> element as its previous sibling,then that context fully resolved is the child's currentcontext.
• If a top-level child has another kind of previous sibling, thenthat sibling's current context is the child's current context.
• All descendants of a<definitions> elementhave the default context as their current context.
• All descendants of other kinds of top-level children have thatchild's current context as their current context.
• All descendants of a top-level child have that child's currentcontext as their current context.

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

We can now describe how contextual information is determined forink 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 overcontextRef which takespriority over the current context. The resulting anonymous contextis the context of this node.
• For other<trace>,<traceGroup> or<traceView>elements, a specific reference (brushRef) takes priorityovercontextRef which takes priority over the enclosing<traceGroup> or<traceView>node's context which takes priority over the current context. Theresulting anonymous context is the context of this node.

5 Canvases

5.1<canvas> element

The<canvas> element provides the virtualcoordinate system, which uniquely identifies a shared virtual spacefor cooperation of ink applications. Together with thetrace-to-canvas coordinate transform (discussed below), it providesa common frame of reference for ink collected in multiple sessionson 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 areapplicable to multiple aspects of the ink markup.

6.1 Mappings

The<mapping> element provides a uniformsyntax for the various uses of mappings in the ink markup. Theelement has anid attribute, which allows a particularmapping to be applied in multiple places. When a previously definedmapping is reused, themappingRef attribute is used to referto the<mapping> element, which might be definedin a<definitions> block. Mappings appear in thefollowing different places in InkML:

1. In a<channel> element of a<traceFormat>, the<mapping>element is used to describe the transformation from the valuesactually produced by the device to the values recorded in the tracedata.
2. Used by a<canvasTransform>, a mapping maybe used to specify the forward or inverse transformations betweenan ink source and a canvas coordinate system.

InkML supports several types of mappings: unknown, identity,lookup table, affine map, formula (specified using a subset ofMathML [MATHML2]) and cross product. The mapping type is indicated by thetype attribute of a<mapping> element.Note: If no mapping appears for a<channel>, itdefaults to "unknown", which is safer than assuming that 'X' isidentical to the device's 'X' since some filtering or modificationscould have been applied. Furthermore, one can specify whether theresults of a mapping expression are absolute or relative to thecurrent data value. This is done by means of theapplyattribute. For lookup table mappings in particular, one candetermine how to interpret intermediate mapping values. This isspecified using theinterpolation 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 schemanamespace [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/>      <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/>      <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 bindingchannels to entities (variable names, lookup table columns) withina mapping, and thus it supports the reuse of predefined mappings.For each type of mapping, the relevant bindings can be expressed bythe combined usage of the<bind> element'sattributes, which aresource,target,columnandvariable.

For an identity mapping (type="identity"), if the sourcechannel has a different name than the channel being defined, thiscan be specified using a<bind> element with asource attribute. In the following markup, the<traceFormat> channel X contains unmanipulateddata from the device's devX channel.   When the mappingtype is an identity mapping, the<bind> elementsource attribute is required, and the otherattributestarget,column, andvariable must not be present.

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

Within a mapping formula (type="mathml"), the variablenames in the formula need to be bound to particular channel names.This is specified using a combination ofsource andvariable attributes for binding inputs of the formula, andtarget andvariable for the output of the formula.This is useful if the same mapping formula is to be reused acrossmultiple channels, like X and Y for example.  When the mappingtype is an mathml mapping thecolumn attribute forthe<bind> element must not be present.

<mapping xml:id="m06" type="mathml">   <bind 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 toby the variable name Q in the mapping expression "Q+10".

For a lookup table (type="table"), each index column mustbe bound to the channel that provides the input for the lookupoperation. This is done with a<bind> elementthat specifiessource andcolumn attributes.Similarly, each value column must be bound to the channel thatreceives the output of the lookup. Its<bind>element specifiestarget andcolumn.   Whenthe mapping type is a lookup mapping thevariableattribute for the<bind> element must not bepresent.

<mapping xml:id="m07" type="table">   <bind 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/>      <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 "*" unitunitPrimitive ::= 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 differentscenarios. Ink markup data may be transmitted in substantially realtime while exchanging ink messages, or ink documents may bearchived for later retrieval or processing. InkML has been designedwith both of these uses in mind, and it is natural to use InkML ina particular way in each of these settings.

These settings illustrate two different styles of ink generationand usage. In the later, the markup must facilitate the incrementaltransmission of a stream of ink data, while in the former, themarkup should provide the structure necessary for operations suchas search and interpretation. In order to support both cases, InkMLprovides archival and streaming modes of usage. These are notdistinct and incompatible languages, but rather are two stylizedways of using InkML.

7.1 Archival Applications

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

In archival usage, contextual elements occur within one or more<definitions> elements and are assignedidentifiers using the id attribute. References to defined elementsare made using the correspondingbrushRef,traceFormatRef, andcontextRef attributes. This isillustrated 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"), atraceFormat ("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. Notethe use of thebrushRef,traceFormatRef,canvasRef andcanvasTransformRef attributes to referto previously defined<brush>,<traceFormat><canvas> and<canvasTransform> elements.

Within the scope of a<definitions> element,unspecified attributes of a<context> elementare assumed to have their default values. The<definitions> block below defines "context1",which is comprised of "canvasA" with the default canvasTransformand traceFormat (the identity mapping and a traceFormat consistingof 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 overridethe values of a previously defined context by including acontextRef attribute, so the following block defines "context2"which shares the same canvas ("canvasA") and traceFormat (thedefault format) as "context1", but has a different canvasTransformand 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 specifytheir context through the use of contextRef and brushRefattributes, or they can have their context provided by an enclosingtraceGroup. In the following example, traces "t001" and "t003" havethe context defined by "context1", while trace "t002" has a contextconsisting 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 alsooverride the context or brush specified by the traceGroup. In thefollowing example, traces "t001" and "t003" have their contextspecified by "context1" while trace "t002" overrides the defaultbrush 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 overrideits brush, as in the following example which assigns the contextspecified 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 straightforwardlydetermine the context for a given trace by examining only the<definitions> blocks within the markup and theenclosing traceGroup for the trace.

7.2 Streaming Applications

Streaming ink applications present digital ink traces insequential time order. Contextual information is inserted into thestream of ink traces, as needed, to provide interpretation for theink strokes. These changes to the current trace context are givenby<context> elements. These may directlycontain brush, trace format and other information or which mayrefer to previously seen such elements. This corresponds to anevent-driven model of ink generation, where events which result incontextual changes map directly to elements in the markup.

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

The appearance of a<brush> element in theink markup sets the current brush attributes, leaving all othercontextual values the same. Likewise, the appearance of a<traceFormat> element sets the currenttraceFormat, and the appearance of a<context>element sets the current context.

Outside of a<definitions> block, any valueswhich are not specified within a<context>element are taken from the current context. For instance, the<context> element in the following examplechanges the current brush from "penB" to "penA", leaving thecanvas, canvasTransform, and traceFormat unchanged from trace"t001" to trace "t002". That is, each context element is taken toinherit 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 thefollowing:

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

Brushes, traceFormats, and contexts which appear outside of a<definitions> block and contain anidattribute both set the current context and define contextualelements 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 valuesspecified in the<context> element.

A previously defined context is referenced using thecontextRef 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 alsooverride values of a previously defined context by including both acontextRef attribute and one or more of thecanvasRef,canvasTransformRef,traceFormatReforbrushRef 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 andoverrides values from a previous context can itself be reused, sothe 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 idhas the effect of taking a "snapshot" of the current context whichcan then be reused. The element:

<context xml:id="context3"/>

defines "context3", whose values consist of the currentcanvasRef, canvasTransform, traceFormat, and brush at the pointwhere the element occurs (note that since "context3" does notspecify any values, the element has no effect on the currentcontext).

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

While it is possible to wait and generate each trace as it iscompleted, this can lead to considerable latency from the startingtime with long strokes.  This may be avoided bygenerating traces of partial strokes and using continuationtraces.

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

7.3 Archival and Streaming Equivalence

The following examples of archival and streaming ink markup dataare equivalent, but they highlight the differences between the twostyles:

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 simplydetermined by the<trace> element, its enclosingtraceGroup, and contextual elements defined in the<definitions> block, while in the streamingcase, the context for a trace can depend on the entire sequence ofcontext changes up to the point of the<trace>element.

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

The two styles of ink markup are equally expressive, but imposedifferent requirements on the ink markup processor and generator.Tools to translate from streaming to archival style might also beof 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 (seeAppendix E) and having an XML Prolog and root element as specified inSection 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.