Assert ID | Feature | Section |
---|---|---|
1560 | The inkml:mapping element | 6.1 |
1570 | The inkml:bind element | 6.1.2 |
1580 | The inkml:table element | 6.1.3 |
1590 | The inkml:affine element | 6.1.4 |
<ink>
element
●3Traces and Trace Formatting
●3.1 Trace Formats
●3.1.1 <traceFormat>
element
●3.1.2 <channel>
element
●3.1.3 <intermittentChannels>
element
●3.1.4 Orientation Channels
●3.1.5 Color Channels
●3.1.6 Width Channel
●3.1.7 Time Channel
●3.1.8 User Defined Channels
●3.1.9 Specifying Trace Formats
●3.2 Traces
●3.2.1 <trace>
element
●3.3 Trace Collections
●3.3.1 <traceGroup>
element
●3.3.2 <traceView>
element
●4Contexts
●4.1 The <context>
element
●4.2 Ink Sources
●4.2.1 <inkSource>
element
●4.2.2 <sampleRate>
element
●4.2.3 <latency>
element
●4.2.4 <activeArea>
element
●4.2.5 <sourceProperty>
element
●4.2.6 <channelProperties>
element
●4.2.7 <channelProperty>
element
●4.3 Brushes
●4.3.1 <brush>
element
●4.3.2 <brushProperty>
element
●4.4 Timestamps
●4.4.1 <timestamp>
element
●4.5 The Default Context
●4.6 Context Priority
●5Canvases
●5.1 <canvas>
element
●5.2 <canvasTransform>
element
●5.3 The Default Canvas
●6Generics
●6.1 Mappings
●6.1.1 <mapping>
element
●6.1.2 <bind>
element
●6.1.3 <table>
element
●6.1.4 <affine>
element
●6.2 Definitions
●6.2.1 <definitions>
element
●6.3 Annotations
●6.3.1 <annotation>
element
●6.3.2 <annotationXML>
element
●6.4 Units
●7Archives and Streams
●7.1 Archival Applications
●7.2 Streaming Applications
●7.3 Archival and Streaming
Equivalence
●8Conformance
●8.1 Conforming InkML Documents
●8.2 Using InkML with other Namespaces
●8.3 Conforming InkML Processors
●AAcknowledgements
●BImplementation Guidelines
●CReferences
●DThe InkML Media Type
●D.1 Registration of MIME
media type application/inkml+xml
●D.2 Fragment Identifiers
●EXML Schema
●FChanges from Previous Working
Draft
<annotation
XML>
.)
Additionally, InkML could be embedded within other XML
documents.
<ink>
element. The fundamental data element in
an InkML file is the <trace>
. A trace represents
a sequence of contiguous ink points, where each point captures the
values of particular quantities such as the X and Y coordinates of
the pen's position. A sequence of traces accumulates to meaningful
units, such as characters, words or diagrams.
In its simplest form, an InkML file with its enclosed traces
looks like this:
<ink xmlns="http://www.w3.org/2003/InkML"> <trace> 10 0, 9 14, 8 28, 7 42, 6 56, 6 70, 8 84, 8 98, 8 112, 9 126, 10 140, 13 154, 14 168, 17 182, 18 188, 23 174, 30 160, 38 147, 49 135, 58 124, 72 121, 77 135, 80 149, 82 163, 84 177, 87 191, 93 205 </trace> <trace> 130 155, 144 159, 158 160, 170 154, 179 143, 179 129, 166 125, 152 128, 140 136, 131 149, 126 163, 124 177, 128 190, 137 200, 150 208, 163 210, 178 208, 192 201, 205 192, 214 180 </trace> <trace> 227 50, 226 64, 225 78, 227 92, 228 106, 228 120, 229 134, 230 148, 234 162, 235 176, 238 190, 241 204 </trace> <trace> 282 45, 281 59, 284 73, 285 87, 287 101, 288 115, 290 129, 291 143, 294 157, 294 171, 294 185, 296 199, 300 213 </trace> <trace> 366 130, 359 143, 354 157, 349 171, 352 185, 359 197, 371 204, 385 205, 398 202, 408 191, 413 177, 413 163, 405 150, 392 143, 378 141, 365 150 </trace> </ink>These traces consist simply of X and Y value pairs, and may look like this when rendered:
<traceFormat>
element. These
coordinates may provide values for such quantities as pen position,
angle, tip force, button states and so on.
Information about the device used to collect the ink (e.g., the
sampling rate and resolution) may be specified with the
<inkSource
>
element.
Ink traces can have certain attributes such as color and width,
writer identification, pen modes (eraser versus writing), and so
on. These and other attributes are captured using the
<brush>
element. Traces that share the same
characteristics, such as being written with the same brush, can be
grouped together with the <trac
eGroup>
element.
Ink traces may also be organized into collections for
application-specific purposes either by grouping the traces objects
themselves, using the <traceGroup>
element, or
by reference, using the <t
raceView>
element.
Certain applications, such as collaborative whiteboards (where
ink coming from different devices is drawn on a common canvas) or
document review (where ink annotation from various sources are
combined), will require ink sharing. The
<context>
element allows representation and
grouping of the pertinent information, such as the trace format,
brush, and canvas. Canvas transformations allow ink from different
devices to be combined and manipulated by multiple parties.
InkML supports the semantic labeling of traces with attributes
on traces or collections of traces. These may be given with either
<
annotation>
, for text, or
<annota
tionXML>
, for XML, using
application-defined encodings.
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).
<ink>
element is
written prior to processing. For ease of implementation in archival
mode, referenced elements should be defined inside a declaration
block using the <definition
s>
element (see The Default Context section, the Definitions section, and the Archival Applications section).
Streaming ink applications, on the other hand, transmit digital
ink as it is captured, such as in the electronic whiteboard example
mentioned above. In order to support a streaming style of ink
markup generation, the InkML language supports the notion of a
"current" state (e.g., the current brush) and allows for
incremental changes to this state.
htt
p://www.w3.org/2003/InkML
The media type of InkML document is
application/inkml+xml
. See the Media Type definition for details. This
media type is expected to be registered with IETF.
<ink>
element
ink
element is the root element of any InkML
instance. When combining InkML and other XML elements within
applications, elements from different namespaces must be
disambiguated by use of the namespace qualifier. The allowed
sub-elements of the ink
element can occur any number
of times, in any order.
documentID
contents. The value of this property is an
opaque URI whose interpretation is not defined in this
specification.
<ink xmlns="http://www.w3.org/2003/InkML" documentID="uuid:6B29FC40-CA47-1067-B31D-00DD010662DA"> ... </ink>
<trace>
is the basic element used to record
the trajectory of a pen as the user writes digital ink. More
specifically, these recordings describe sequences of connected
points. On most devices, these sequences of points will be bounded
by pen contact change events (pen-up and pen-down), although some
devices may simply record proximity and force data without
providing an interpretation of pen-up or pen-down state.
The simplest form of encoding specifies the X and Y coordinates
of each sample point. For compactness, it may be desirable to
specify absolute coordinates only for the first point in the trace
and use delta-x and delta-y values to encode subsequent points.
Some devices record acceleration rather than absolute or relative
position; some provide additional data that may be encoded in the
trace, including Z coordinates or tip force, or the state of side
switches or buttons.
These variations in the information available from different ink
sources, or needed by different applications, are supported in
InkML through the <traceFormat>
and
<trace>
elements. The
<traceForm
at>
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 <traceForm
at>
is
specified, a default encoding format of X followed by Y coordinates
is assumed.
Traces generated by different devices, or used in differing
applications, may contain different types of information. InkML
defines channels to describe the
data that may be encoded in a trace.
A channel can be characterized as either regular,
meaning that its value is recorded for every sample point of the
trace, or intermittent, meaning that its value may change
infrequently and thus will not necessarily be recorded for every
sample point. X and Y coordinates are examples of likely regular
channels, while the state of a pen button is likely to be an
intermittent channel.
<traceFormat>
element
<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 <ch
annel>
s, giving the regular
channels (if any), followed by an optional
<intermittentChannels>
section. The order of the
coordinates in each point of a trace is determined by the order of
the <chan
nel>
elements in the trace format,
including those from the intermittent channels part.
The <context>
element may use the traceFormatRef
attribute to refer to a <traceFormat>
by it's id. If no <traceFormat>
is specified in an InkML file, an application defined default trace format is
used. The default trace has the reserved id "DefaultTrace
Format
"
and may be explicitly referenced using the
URI "#DefaultT
raceFormat
".
<channel>
element
<channel>
element, with various attributes.
The required name attribute specifies the interpretation
of the channel in the trace data. The following case sensitive channel names, with
their specified meanings, are reserved:
channel name | dimension | default unit | interpretation |
---|---|---|---|
X | length | mm | X coordinate. This is the horizontal pen position on the writing surface, increasing to the right for +ve orientation. |
Y | length | mm | Y coordinate. This is the vertical position on the writing surface, increasing downward for +ve orientation. |
Z | length | mm | Z coordinate. This is the height of pen above the writing surface, increasing upward for +ve orientation. |
F | force | % | pen tip force |
S | tip switch state (touching/not touching the writing surface) | ||
B1...Bn | side button states | ||
OTx | angle | deg | tilt along the x-axis |
OTy | angle | deg | tilt along the y-axis |
OA | angle | deg | azimuth angle of the pen (yaw) |
OE | angle | deg | elevation angle of the pen (pitch) |
OR | angle | deg | rotation (counter-clockwise rotation about pen axis ) |
C | color value as an RGB octet triple (i.e. #000000 to #FFFFFF). | ||
CR,CG,CB | color values (Red/Green/Blue) | ||
CC,CM,CY,CK | color values (Cyan/Magenta/Yellow/Black) | ||
A | transparency (device-specific encoding) | ||
W | length | mm | stroke width (orthogonal to stroke) |
BW | length | mm | brush width |
BH | length | mm | brush height |
T | time | ms | time (of the sample point) |
<timestamp>
element. For other
application defined channels the URI is application-dependent.
Typically, a channel in the <tra
ceFormat>
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.
<intermittentChannels>
element
<mappin
g>
element can be
employed to specify an applied sine transformation. While it is not
forbidden to use channels from different groups together (i.e. from
more than one of {OA, OE} and {OTx, OTy}), applications will not
normally do this.
The third degree of freedom in orientation is generally defined
as the rotation of the pen about its axis. This is potentially
useful (in combination with tilt) in application such as
illustration or calligraphy, and signature verification.
<b
rush>
element.
It is legitimate for an application to have an accessibility
mode or alternative rendering mode where the explicit color values
in the InkML are reinterpreted as other colors for better
accessibility or suitability of the rendering device. Examples of
this would be mapping color to black and white for monochrome
devices or to high-contrast colors for greater visibility.
<brushProperty>.
As with the color channels, the width channels are intended for
use when this quantity is part of the data itself and hence
potentially changing from one sample to the next. Strokes with
constant width may more economically be described with reference to
a <br
ush>
element with width
and height properties.
<traceFormat>
of the
trace.
As with the other predefined channels, the meaning of the integer or decimal
values recorded by the time channel in a given trace is defined by the trace's
associated <traceFormat>. In the case of
the time channel, its <channel> element contains
both a units and respectTo attribute.
The units attribute gives the units of the recorded time
values, and the respectTo attribute describes the frame of
reference for those recorded values. The value of the
respectTo attribute is a reference to a time stamp. If it is
not given, the time channel values are relative to the beginning
timestamps of the individual traces in which they appear.
The following example defines a time channel whose values for a
given point are the relative to the timestamp referred to by
#ts1:
<channel name="T" type="integer" units="ms" respectTo="#ts1" />If no <traceFormat> information is provided, or if no value is specified for the respectTo attribute, the ink processor cannot make any assumption about the relative timing of points within different traces. Likewise, if no units are specified, no assumption can be made about the units of the time channel data.
<
traceFormat>
which reports decimal-valued X and
Y coordinates for each point, and intermittent boolean values for
the states of two buttons B1 and B2, which have default values of F
("false"):
<traceFormat xml:id="xyb1b2"> <channel name="X" type="decimal"> <mapping type="identity"/> </channel> <channel name="Y" type="decimal"> <mapping type="identity"/> </channel> <intermittentChannels> <channel name="B1" type="boolean" default="F"> <mapping type="identity"/> </channel> <channel name="B2" type="boolean" default="F"> <mapping type="identity"/> </channel> </intermittentChannels> </traceFormat>The appearance of a
<traceFormat>
element in an InkML file both
defines the format and installs it as the current format for
subsequent traces except within a <def
initions>
block (see Specifying Trace Formats). The id
attribute of a <traceFormat>
allows the format
to be reused by multiple contexts (see the Context section). If no
<traceFormat>
is specified, the following
default format is assumed:
<traceFormat xml:id="DefaultTraceFormat"> <channel name="X" type="decimal"/> <channel name="Y" type="decimal"/> </traceFormat>Thus, in the simplest case, an InkML file may contain nothing but
<trace>
elements within an <ink
>
element.
<trace>
element
continu
ation
has values "end" or
"middle", Default: none
contextRef = xsd:anyURI
The context for this trace. Any values in this
context over-ride the values in the inherited context.
Required: no, Default:
"#DefaultC
ontext
," unless this
<trace> is
contained within a <traceGroup>, then inherit
from the <traceGroup>.
brushRef = xsd:anyURI
The brush for this trace.
Required: no, Default: Inherited from context.
duration = xsd:decimal
The duration of this trace, in
milliseconds.
Required: no, Default: none
timeOffset = xsd:decimal
The relative timestamp or time-of-day for the
start of this trace, in milliseconds.
Required: no, Default: none
<trace>
element. It is
described using the subset of Extended Backus-Naur Form defined in the Notation
section of the Extensible
Markup Language (XML) 1.0 (Fourth Edition) specification [EBNF].
This subset of EBNF includes the following
notation:
●*: 0 or more
●+: 1 or more
●?: 0 or 1
●(): grouping
●|: separates alternatives
●double or single quotes surround literals
●#x precedes hex character codes
The grammar is as follows:
trace ::= point ("," point)* ","? wsp* point ::= (wsp* value)+ wsp* value ::= difference_order? wsp* "-"? wsp* number | "T" | "F" | "*" | "?" number ::= (decimal | double | hex) double ::= decimal ("e"|"E") ("+"|"-")? digit+ decimal ::= digit+ ("." digit*)? | "." digit+ hex ::= "#" (digit | "A" | "B" | "C" | "D" | "E" | "F")+ difference_order ::= ("!" | "'" | '"') digit ::= ("0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9") wsp ::= (#x20 | #x9 | #xD | #xA)Additionally, wsp may occur anywhere except within a decimal, floatorhex and must occur if required to separate two values. Otherwise the longest token is matched. For example, "3245" requires an internal wsp character if it is to be interpreted as two decimal numbers, "32" and "45". On the other hand, "0.923.45" will be interpreted as "0.923" and ".45". The number of value tokens appearing within each point must be at least equal to the number of regular channels and be no more than the number of regular channels plus the number of intermittent channels. 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
<tra
ceFormat>
element.
The type attribute of a <trace>
indicates the pen contact state (either "penUp
" or
"penDown
") during its recording. A value of
"ind
eterminate
" is used if the contact-state is
neither pen-up nor pen-down, and may be either unknown or variable
within the trace. For example, a signature may be captured as a
single indeterminate trace containing both the actual writing and
the trajectory of the pen between strokes. The values of the tip switch
state channel "S", if present in the trace, overrides the value of the
type attribute.
If a continuation
attribute is present, it
indicates that the current trace is a continuation trace, i.e. its
points are a temporally contiguous continuation of (and thus should
be connected to) another trace element. The possible values of the
attribute are:
●begin
: the current trace is the first of the set
of continuation traces
●end
: the current trace is the last of the set of
continuation traces
●middle
: the current trace is a continuation trace,
but is neither the first nor the last in the set of traces
If the current trace is a continuation trace but is not the
first trace in the set (i.e. the cont
inuation
attribute has value midd
le
orend
) then a
priorRef
attribute must be present and must contain
the URI of the trace of which the current trace is a continuation.
A begin
ormiddle
trace can be the prior
trace for exactly one trace. An end
trace cannot be
the prior trace of any other trace.
Regular channels may be reported as explicit values,
differences, or second differences: Prefix symbols are used to
indicate the interpretation of a value: a preceding exclamation
point (!
) indicates an explicit value, a single quote
('
) indicates a single difference, and a double quote
prefix ("
) indicates a second difference. If there is
no prefix, then the channel value is interpreted as explicit,
difference, or second difference based on the last prefix for the
channel. If there is no last prefix, the value is interpreted as
explicit.
A second difference encoding must be preceded by a single
difference representation; which, in turn, must be preceded with an
explicit encoding.
All traces must begin with an explicit value, not with a first
or second difference. This is true of continuation traces as well.
This allows the location and velocity state information to be
discarded at the end of each trace, simplifying parser
design. This is true for continuation traces.
Both regular and intermittent channels may be encoded with the
wildcard character "*". This wildcard character means either that
the value of the channel remains at the previous channel value (if
explicit), or that the channel continues integrating with the
previous velocity or acceleration values, as appropriate.
Intermittent channels may be encoded with the wildcard character
"?". This means that a value of a channel is not given at that
point. It is useful when there are several independent intermittent
channels, and they do not always report simultaneously, e.g.
<trace> 11 12 9, 21 22 ? T, 31 32, 41 42 5, 51 52 ? F</trace>Booleans are encoded as "T" or "F". For each point in the trace, regular channel values are reported first in the order given by the
<channel>
elements of the applicable <traceFormat>
. All
regular channels must be reported, if only with the explicit
wildcard "*". If any intermittent values are reported for the
point, they are given next, in the order given by the
<intermittentChannels>
elements of the
applicable <traceForm
at>
. Unreported
intermittent channels are interpreted as though they were given by
the wildcard "*".
Here is an example of a trace of 11 points, using
the following traceFormat:
<traceFormat> <channel name="X" type="decimal"/> <channel name="Y" type="decimal"/> <intermittentChannels> <channel name="B1" type="boolean" default="F"/> <channel name="B2" type="boolean" default="F"/> </intermittentChannels> </traceFormat> <trace xml:id="id4525abc"> 1125 18432,'23'43,"7"-8,3-5,7 -3,6 2,6 8,3 6 T,2 4*T,3 6,3-6 F F </trace>The trace is interpreted as follows:
Trace | X | Y | vx | vy | B1 | B2 | Comments |
---|---|---|---|---|---|---|---|
1125 18432 | 1125 | 18432 | ? | ? | F | F | button default values |
'23'43 | 1148 | 18475 | 23 | 43 | F | F | velocity values |
"7"-8 | 1178 | 18510 | 30 | 35 | F | F | acceleration Values |
3-5 | 1211 | 18540 | 33 | 30 | F | F | implicit acceleration no whitespace needed |
7 -3 | 1251 | 18567 | 40 | 27 | F | F | optional whitespace |
6 2 | 1297 | 18596 | 46 | 29 | F | F | whitespace required |
6 8 | 1349 | 18633 | 52 | 37 | F | F | |
3 6 T | 1404 | 18676 | 55 | 43 | T | F | an optional value |
2 4*T | 1461 | 18723 | 57 | 47 | T | T | wildcard |
3 6 | 1521 | 18776 | 60 | 53 | T | T | optional keep last |
3-6 F F | 1584 | 18823 | 63 | 47 | F | F | optionals |
<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>Note: see Appendix B Implementation Guidelines for information about reducing file or stream size.
<trace
Group>
and
<traceView>
elements. These allow multiple
traces or groups to be treated as single units for the purposes of
referencing, attaching context information, semantic labeling, or
application-specific needs. The <traceGrou
p>
element gathers <trace>
other
<
traceGroup>
or<traceView>
elements into a unit. The <traceView>
element
refers to existing <trace>
,
<
traceGroup>
or other
<traceView>
elements to provide alternative
views or organization on the ink. For example, a diagramming
application may record a stream of fixed-length
<trace>
packages, organized as continuations,
and use <
traceGroup>
elements containing
<
traceView>
elements to record the logical
structure of the diagram.
<traceGroup>
element
#DefaultC
ontext
," unless this
<traceGroup> is
contained within another <traceGroup>, then inherit
from the containing <traceGroup>.
brushRef = xsd:anyURI
The brush associated with this <traceGroup>.
Required: no, Default: Inherited from context
<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 <traceGr
oup>
. In the following example the two
traces enclosed in the <tr
aceGroup>
share the
same brush (see the Brushes section for a
description of brushes).
<traceGroup brushRef="#penA"> <trace>...</trace> <trace>...</trace> </traceGroup>The
<traceGroup>
element may be used for
various purposes, such as to group traces according to their
properties at the time of capture or according to computed
recognition results. The element may be nested, and it may be used
as a generic grouping mechanism, e.g. for the semantic labeling of
traces.
Trace groups are the primary mechanism for assigning
<context>
to traces in archival ink markup. For
additional details about this usage, see the Archival Applications section.
<traceView>
element
<trace>
, <tr
aceGroup>
or<traceView>
element.
Required: yes, Default: none
from = xsd:integer[ ':' xsd:integer ]*
The index of the first item (point, trace or
group) in the trace or trace group that this
<traceVi
ew>
element references.
Required: no, Default: the index of the first
referenced point (see prose)
to = xsd:integer[ ':' xsd:integer ]*
The index of the last item (point, trace or
group) in the trace or trace group that this
<traceVie
w>
element references.
Required: no, Default: the index of the last
referenced point (see prose)
<traceView>
element is used to include
traces by reference from the current document or other documents. A
common use is to group a collection of
<traceView>
elements in a
<traceGroup>
to provide annotations.
Together, traceDataRef, from
and torefer to another element and select part of
it. A traceDataRef attribute may refer to a
<trace>
, a <traceGroup>
or
another <traceV
iew>
.
A missing from attribute is equivalent to
selecting the first point in the (recursively) first child of the
referenced element. A missing toattribute is
equivalent to selecting the last point in the (recursively) last
child of the referenced element. With these defaults, the
<traceView>
selects the portion of the
referenced element from the first point to the last point,
inclusive. If neither a tonor
from attribute is given, this implies the entire
referenced element is selected.
Any value of a fromorto
attribute is a colon-separated list of integers, whose meaning is
defined as follows: An empty list of integers selects the entire
referenced object (point, <trace>
,
<traceGr
oup>
or<traceView>
).
If the list is non-empty, then its first element is taken as a
1-based index into the referenced object, and the remaining list is
used to select within the object. It is an error to try to select
within a single point. The rationale to allow selection using this
colon-separated-integer indexing scheme is that the desired ink
selections in a referenced document might not have id attributes on
the desired nodes.
If the referenced object is a <t
raceView>
,
then the indexing is relative to the tree selected by the
<traceView>
, not relative to the original
object.
If a <traceGroup>
contains continuation
traces, they are counted independently.
<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>With traceDataRef "#L1", the from index "2" refers to the point (921, 922). With traceDataRef "#L2", the from index "2" refers to the
<traceGroup>
with id "L2-Larry",
the index "4:1:1" refers to the element with id "L2-Moe", the index
"4:1:1:2" refers to the point (521, 522), and the index "4:1:1:2:1"
is illegal.
The <traceGroup>
with id "L3" selects the
following structure
<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>and the
<traceView>
with id "L4" selects
<traceGroup> <trace>931 932</trace> <traceGroup> <traceGroup> <trace>221 212, 221 222</trace> <trace>311 312</trace> </traceGroup> </traceGroup> </traceGroup>
<context>
element
which provides a means to associate a defined context with trace
data.
The format of trace data -- both in the channels available and
their particulars -- may vary from device to device, including from
stylus to stylus with the same tablet. Therefore, the
<context>
element may refer to or contain a
specific <traceFormat>
and <ink
Source>
element
for the device.
As the ink is generated, there may be various context-dependent
attributes associated with the pen. For this, a <brush>
element may be
used to record the attributes of the pen during the capture of the
digital ink.
The start times of traces are often given relative to a
specified point in time. A context may provide a <timestamp>
element for
this.
For applications that require the sharing of ink, contexts may
relate their ink to a shared canvas, given by a <canvas>
element. The
trace format of the ink source is related to the trace format of a
shared canvas by means of a <canvasTransform>
element.
<context>
element
<cont
ext>
element
and its attributes. The context element both provides access to a
useful shared context (canvas) and serves as a convenient
agglomeration of contextual attributes. It is used by the <traceGroup>
and <traceView>
elements to define the complete shared context of a group of traces
or may be referred to as part of a context change in streaming
mode. In either mode, individual attributes may be overridden at
time of use. Additionally, individual traces may refer to a
previously defined context (again optionally overriding its
attributes) to describe a context change that persists only for the
duration of that trace.
Although the use of the <context
>
element and
attributes is strongly encouraged, default interpretations are
provided so that they are not required in an InkML file if all
trace data is recorded in the same virtual coordinate system, and
its relationship to device coordinates is either not needed or
unknown.
<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
Each constituent part of a context may be provided either by a
referencing attribute or as a child element. If both are given,
then the child element is used. Thus it is possible to have either
a traceFormatRef attribute or a
<t
raceFormat>
child element. If both are given,
then the <traceForm
at>
child is used and the
attribute is ignored.
<
inkSource>
element, which supports capture of
basic information about the make and model of the device and the
ink channels captured, as well as very detailed information about a
number of source characteristics.
Some of these characteristics are already commonly used in
digitizer specifications, while others are somewhat more esoteric,
but nonetheless potentially very useful. In general, these source
characteristics describe signal fidelity, allow understanding of
the quality of the data, and impose some limits on how the data can
be used. They are not intended to be used for repair of bad data
from the source.
<inkSource>
element
<i
nkSource>
element.
Required: yes
manufacturer = xsd:string
String identifying the digitizer device
manufacturer.
Required: no, Default: unknown
model = xsd:string
String identifying the digitizer model.
Required: no, Default: unknown
serialNo = xsd:string
Unique manufacturer (or other) serial number
for the device.
Required: no, Default: unknown
specificationRef = xsd:anyURI
URI of a page providing detailed or additional
specifications.
Required: no, Default: unknown
description = xsd:string
String describing the ink source, especially
one implemented in software.
Required: no, Default: unknown
<inkSource xml:id="mytablet" manufacturer="Example.com" model="ExampleTab 2000 USB" specificationRef="http://www.example.com/products/exampletab/2000usb.html"> <traceFormat> <channel name="X" ... /> <channel name="Y" ... /> <channel name="F" ... /> </traceFormat> <sampleRate uniform="true" value="200"/> <latency value="50"/> <activeArea size="A6" height="100" width="130" units="mm"/> <sourceProperty name="weight" value="100" units="g"/> <channelProperties> <channelProperty channel="X" name="resolution" value="5000" units="1/in"/> <channelProperty channel="Y" name="resolution" value="5000" units="1/in"/> <channelProperty channel="Y" name="peakRate" value="50" units="cm/s"/> <channelProperty channel="F" name="resolution" value="1024" units="dev"/> </channelProperties> </inkSource>The
<inkSource>
element will allow
specification of:
●Manufacturer, model and serial number (of a hardware
device)
●Text description of source, and reference (URI) to detailed or
additional information
●Trace format - regular and intermittent channels reported by
source
●Sampling rate, latency and active area
●Additional properties of the device in the form of
name-value-units triples
●Properties of individual channels
<sampleRate>
element
<sampleRate>
element captures the rate at
which ink samples are reported by the ink source. Many devices
report at a uniform rate; other devices may skip duplicate points
or report samples only when there is a change in direction. This is
indicated using the uniform
attribute, which must be
designated "false" (non-uniform) if any pen-down points are
skipped or if the sampling is irregular.
A time channel should be used to get time information when the
sampling rate is not uniform. When the sampling rate is not
uniform, the value
attribute of the <samp
leRate>
element specifies
the maximum sampling rate.
<sampleRate uniform="true" value="200"/>
<latency>
element
<latency>
element captures the basic
device latency that applies to all channels, in milliseconds, from
physical action to the API time stamp. This is specified at the
device level, since all channels often are subject to a common
processing and communications latency.
<latency value="50"/>
<activeArea>
element
<activeArea size="A6" height="100" width="130" units="mm"/>
<sourceProperty>
element
<sourceProperty>
element provides a
simple mechanism for the capture of additional numericorstring properties of the ink source as a
whole.
<sourceProperty name="weight" value="100" units="g"/>
<channelProperties>
element
<channelProperties>
element is meant for
describing properties of specific channels reported by the ink
source. Properties such as range and resolution may be specified
using corresponding elements. For more esoteric properties (from a
lay user's standpoint) the generic <channelProperty> element may
be used.
<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>
element
<channelProperty>
element provides a
simple mechanism for the capture of additional numericorstring properties of specific channels when known
and appropriate. The following channel property names, with their
specified meanings, are reserved. Other properties may be defined
by the user.
Property name | Interpretation |
---|---|
threshold | Threshold - e.g. for a binary channel, the threshold force at which the tip switch is activated |
resolution | Resolution - the scale of the values recorded. This may be expressed as fractions of a unit, e.g. 1/1000 in (inches), 0.1 mm, 1 deg (degrees). It may also be expressed, more popularly, in inverse units, e.g. "1000 points per inch" would be given as 1000 in units 1/in. |
quantization | Quantization - the unit of smallest change in the reported values. If the value is reported as integer, this is assumed to be the same as the resolution. Note that if decimal values are recorded for resolution, the quantization of the data may be smaller than the "resolution". |
noise | Noise - the RMS value of noise typically observed on the channel. This is distinct from accuracy! It is an indication of the difference observed in the data from the device when the same path is traced out multiple times (e.g. by a robot). |
accuracy | Accuracy - the typical accuracy of the data on the channel (e.g. "0.5 mm", "10 degrees" or "0.1 Newton") This is the typical difference between the reported position and the actual position of the pen tip (or tilt ...) |
crossCoupling | Cross-coupling - the distortion in the data from one channel due to changes in another channel. For example, the X and Y coordinates in an electromagnetic digitizer are influenced by the tilt of the pen. This would be specified by dX/dOTx = ... or max delta X vs. OTx = ... If the influencing channels are also recorded, and the cross-couplings are accurately specified, it may be possible to compensate for the cross-coupling by subtracting the influence, at the expense of higher noise. The cross-coupling is always expressed in the units of the two channels, e.g. if X mm and OTx is in degrees, then cross-coupling is in mm/deg. |
skew | Skew - the temporal skew of this channel relative to the basic device latency, if any. For example, some devices actually sample X and Y at different points in time, so one might have a skew of -5 millisecond, and the other +5 millisecond. |
minBandwidth | Minimum bandwidth (in Hz) - the minimum bandwidth of the channel, in Hz (not samples/second), i.e., the frequency of input motion up to which the signal is accurate to within 3dB. |
peakRate | Peak rate - the maximum speed at which the device can accurately track motion |
distortion | Dynamic distortion, e.g., how velocity affects position accuracy. This is expressed in inverse seconds, e.g. 0.01 mm / mm / s. This kind of distortion is often cross channel, but this specification only allows a generic, channel-specific value. |
<channelProperty channel="F" name="threshold" value="0.1" units="N"/> <channelProperty channel="X" name="quantization" value="0.01" units="mm"/>
<brush>
element
<brush>
element. This element allows for the
definition of reusable sets of brush attributes which may be
associated with traces. For reference purposes, a brush specifies
an identifier which can be used to refer to the brush. A brush can
inherit the attributes of another <brush>
element by including a brushRef attribute which contains the id of
the referenced brush. The brush attributes are stored in
<brushProperty>
child elements. Brushes may be
used to convey information about how a stroke is to be rendered or
simply to distinguish between different types of traces (e.g. an
eraser vs. a pen, different writers). In this later case, all that
matters is that brushes are distinct so no brush properties are
necessary.
Brush attributes are associated with traces using the brushRef
attribute. When it appears as an attribute of an individual
<trace>
, the brushRef specifies the brush
attributes for that trace. When it appears as an attribute of a
<traceGroup>
element, the brushRef specifies the
common brush attributes for all traces enclosed in the
<traceGroup>
. Within the
<t
raceGroup>
, an individual trace may still
override the traceGroup's brush attributes using a brushRef
attribute.
Brush attributes can also be associated with a context by
including the brushRef attribute on a <
context>
element. Any traces which reference the context using a contextRef
attribute are assigned the brush attributes defined by the context.
If a trace includes both brushRef and contextRef attributes, the
brushRef overrides any brush attributes given by the
contextRef.
The default brush may be explicitly specified using the URI
"#Def
aultBrush
". The id "DefaultBrus
h
"
is therefore reserved and may not be used as the id of a user defined <brush>
element. The default brush is identical to a user defined brush that has
not explicit
<brushProperty>
child elements.
In streaming ink markup, brushes are assigned to a trace
according to the current brush, which can be set using the
<context>
and <brush>
elements. See section Streaming
Applications for a detailed description of streaming mode.
<brushProperty>
element
<brushProperty>
element provides a
mechanism for the storage of named properties of brushes. The
following brush property names, with their specified meanings, are
reserved. Other properties may be defined by the user.
Property name | Interpretation | ||||||
---|---|---|---|---|---|---|---|
width | Width of the brush. If the width property is not given and a BW channel is present, the values of the BW channel are used as the brush width. The default value is defined by the application. |
||||||
height | Height of the brush. If a height property is not given and a BH channel is present, the values of the BH channel are used as the brush height. The default value is defined by the application. |
||||||
color | Color of brush as three octets for
RGB. If a color property is not given and color channels are present (C or CR, CG, CB or CC, CM, CY, CK), their values are used for the color. Default is #000000. |
||||||
transparency | Transparency of brush as an integer: 0
is opaque. If a transparency property is not given and the transparency channel (A) is present, its value is used. Default is 0. |
||||||
tip | The type of pen tip:
ellipse, rectangle, or
drop. Ifellipse, then the width property specifies the horizontal diameter, and the height property specifies the vertical diameter. If the height property is absent, its default value is the value of width. Ifrectangle, the width and height properties specify the width and height of the rectangle. If the height property is absent, the default value is the value of width making the brush a square. Ifdrop, the shape is defined by a circle and two tangent lines to a point outside the circle, located above the circle on the vertical axis, as shown in Figure 4. The width property is the diameter the circle part, and the height property is the maximum diameter of the shape. Default is ellipse. If the OR channel is present, the tip shape is rotated counter-clockwise by this amount about its origin. |
||||||
rasterOp | A value that defines how the colors of
the pen and background interact. In the example images below,
the original background is white with the black text 'abc' and it
is overwritten with a single curved yellow ink stroke.
The default value is copyPen, which indicates that the current pen color is used. Applications may define additional rasterOp values. |
||||||
antiAliased | The drawn ink is anti-aliased. Default is true. |
||||||
fitToCurve | The ink is rendered as a series of curves versus as
lines between pen sample points. Default is false. |
||||||
ignorePressure | If true, pressure from the pen tip is ignored and
the width of the ink remains the same regardless of the pressure of
the pen on the tablet surface. If false, the width of the ink gets wider with increased pressure of the pen on the tablet surface. Default is false. |
<brushProperty name="width" value="2" units="cm"/> <brushProperty name="color" value="#FF0000"/>
<timestamp>
element and the timestampRef,
timeOffset and duration attributes of the
<tra
ce>
element. For ease of processing, all
timestamps are expressed in milliseconds. Finer-grained timestamps
are obtained using fractional values.
<timestamp>
element
<timestamp>
element establishes a
reference timestamp which can then be used for relative
timestamping of traces.
At most one of the attributes time, timestampRefortimeString is used. The time thus given, plus the value
of the attribute timeOffset, gives the time value of the
timestamp.
If more than one of time, timeString and
timestampRef are given, then time is used if present.
Failing that, timeString is used.
If none of time, timestampRefortimeString
are given, then the timestamp refers to some unspecified moment in
time. This is useful when the timestamp is referenced by multiple
elements to provide relative timing information.
The four examples below illustrate the establishment of various
reference timestamps. The first <
timestamp>
element, ts001, refers to January 2, 2004 at 7:00am, UTC. The
second establishes timestamp ts002 which refers to January 2, 2004
at 7:10am, UTC (10 minutes after the reference timestamp ts001),
and the third time stamp, ts003, gives the same time using the
timeString attribute. The fourth creates ts004 with time
January 2, 2004 at 7:10:04.32, UTC (4.32 seconds after the
timestamp of trace ts002).
<timestamp xml:id="ts001" time="1073026800000"/> <timestamp xml:id="ts002" timeOffset="600000" timestampRef="#ts001"/> <timestamp xml:id="ts003" timeString="2004-01-02T07:10:00Z"/> <timestamp xml:id="ts004" timeOffset="4320" timestampRef="#ts002"/>
<context>
elements may
occur in a <definiti
ons>
element, elsewhere in
the same document or in other documents. Explicit contexts are
typically used in archival ink applications.
Traces that do not make explicit reference to a context occur in
a default context. This is established by the sequence of elements
in the <ink>
element. Initially the default
context is empty and uses defaults for all properties, including a
default trace format, default canvas, etc. Then, interspersed with
ink data, other elements may occur that alter the default context.
These elements are <brush>
,
<context>
, <traceF
ormat>
,
<inkSource>
and <timestam
p>
.
As the ink is processed from the first child onward, whenever one
of these elements is encountered, it is installed as the default to
be used by traces. These are used by traces that do not otherwise
specify these properties.
The default context may be explicitly specified using the URI
"#D
efaultContext
". The id "Default
Context
"
is therefore reserved and may not be used as the id of a user defined <context>
element.
<co
ntext>
priority over specific references
(brushRef, canvasRef, canvasTransformRef,
inkSourceRef, timestampRef, traceFormatRef),
which take priority over contextRef, which takes priority
over the current context.
The current context is a syntactic notion associated to
each node in an ink document. Roughly speaking, the current context
is changed only by <context>
elements that occur
directly as children to the <ink>
element (i.e.
not inside <definitions>
). It is defined as
follows.
●The first top-level child of an <ink>
element has the default context its current context.
●If a top-level child of an <ink
>
element has
a <context>
element as its previous sibling,
then that context fully resolved is the child's current
context.
●If a top-level child has another kind of previous sibling, then
that sibling's current context is the child's current context.
●All descendants of a <definitio
ns>
element
have the default context as their current context.
●All descendants of other kinds of top-level children have that
child's current context as their current context.
●All descendants of a top-level child have that child's current
context as their current context.
The current context is central to streaming ink applications
(see Streaming).
We can now describe how contextual information is determined for
ink traces.
●For a top-level <trace>
,
<traceG
roup>
or<traceView>
element (i.e. on that occurs as a direct child of an
<ink>
element), a specific reference
(brushRef) takes priority over contextRef which takes
priority over the current context. The resulting anonymous context
is the context of this node.
●For other <trace>
,
<traceGroup>
or<traceView>
elements, a specific reference (brushRef) takes priority
over contextRef which takes priority over the enclosing
<t
raceGroup>
or<traceView>
node's context which takes priority over the current context. The
resulting anonymous context is the context of this node.
<c
anvas>
element, and is typically referred to by one or more
<conte
xt>
elements. These contexts may each have
their own set of ink capture characteristics and trace formats. In
order to map traces from a particular context to a canvas, and vice
versa, each context provides its own canvas transform, inverse
transform or both.
A context neither referencing nor inheriting a canvas uses a
default canvas, sufficient to allow simple single-canvas sharing
without further action on the part of devices or applications.
Each canvas defines its dimensions by giving a
<traceFormat>
element. Its channel declarations
may specify minimum and/or maximum values, an orientation and
units. If no minimum or maximum is given for a channel of integer
or decimal type, then it is unbounded in that direction.
If a canvas is bounded in any direction, then all traces defined
on that canvas must be contained inside its limits. There may be
applications where strokes appear outside of the canvas. In these
cases the processing of out-of-bounds traces is not defined by the
specification.
Although canvases are virtual spaces, each of the coordinates
may be assigned a unit of measure. This allows collaborating
parties to establish a common notion of scale.
An example use for such a shared canvas might be a single ink
markup stream or file that contains traces captured on a tablet
computer, a PDA device, and an opaque graphics tablet attached to a
desktop computer. The size of these traces on each ink source and
corresponding display might differ, yet it may be necessary to
relate these traces to one another. They could represent scribbles
on a shared electronic whiteboard, annotations of a common
document, or the markings of two players in a distributed
tic-tac-toe game.
The trace data for these different ink sessions could be
recorded using the same set of virtual coordinates; however, it is
often useful, and may even be necessary at times, to record the
data in the ink source coordinates, in order to more precisely
represent the original capture conditions, for compactness, or to
avoid round-off errors that might be associated with the use of a
common coordinate system. Thus we define the concept of a "canvas
transform", which can vary according to the ink source. The default
transform is the identity. It is also possible to specify the
mapping from the canvas back to the coordinates of the original
trace format. This is useful in collaborative ink applications
where ink added to the canvas from one source must be interpreted
in the frame of reference of the other sources. It is not always
necessary to specify the inverse transform. If the canvas transform
is given as an affine map of full rank, then it may be inverted
numerically. Likewise if coordinates are transformed by a lookup
table with linear interpolation, then the mapping may be inverted
numerically. In all other cases the inverse transformation must be
provided if the inverse mapping is required.
<canvas>
element
<canvas>
element provides the virtual
coordinate system, which uniquely identifies a shared virtual space
for cooperation of ink applications. Together with the
trace-to-canvas coordinate transform (discussed below), it provides
a common frame of reference for ink collected in multiple sessions
on different devices.
<traceFormat>
element.
Required: no, Default: none.
<canvas>
element must have an associated
<traceFormat>
, which may either be given as a
child element or referred to by a
traceFormatRef attribute. If
both a <traceFormat> element and a
traceFormatRef
attribute are specified, then the element overrides the attribute.
The coordinate space of the canvas is given by the regular channels
of the trace format and any intermittent channels are ignored.
Example:
<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>
element
<canvasTransform>
element is used to
relate two coordinate systems. The source and target coordinate
systems are ultimately defined in terms of
<traceFormat>
elements. These trace formats may
either be given directly, or indirectly by
<inkSource>
, <context>
or
other <canvas>
elements. In general, the source
and target coordinate systems may involve a different number and
type of coordinates, or have different ranges and orientation for
the same dimension.
The contents of the <canvasTrans
form>
consists of one or two <map
ping>
elements.
If there is only one, then it is the mapping from the source to the
target coordinate system, where the meaning of "source" and
"target" is determined by the use. If there are two children, the
first is the mapping from the source to the target and the second
is the inverse mapping from the target back to the source.
The transform and its inverse need not be full inverses in the
mathematical sense. If a transform is from a trace format to a
canvas with fewer coordinates, then the inverse transform may map
from the canvas back to the original trace format by supplying
default values for the coordinates not in the canvas. This would
occur, for example, if a party were sharing ink from a device with
a force channel with a canvas with only spatial coordinates.
For certain classes of mappings, the inverse mapping may be
determined automatically. These are mappings of type "identity",
"affine" (for matrices of full rank), "table" (univariate, with
linear interpolation), and "product" mappings of these. In this
case, it is possible to specify that an inverse should be
determined automatically by giving only the forward transform and
specifying a value of true
for the invertible
attribute. If two <mapping>
elements are
specified, then the invertible attribute is
ignored.
For an application to give only the inverse transform, it should
supply the forward transform as an unknown mapping:
<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>The default canvas may be explicitly specified using the URI "
#De
faultCanvas
". The id "DefaultCa
nvas
"
is therefore reserved and may not be used as the id of a user defined <canvas>
element.
<mapping>
element provides a uniform
syntax for the various uses of mappings in the ink markup. The
element has an idattribute, which allows a particular
mapping to be applied in multiple places. When a previously defined
mapping is reused, the mappingRef attribute is used to refer
to the <mapping>
element, which might be defined
in a <definitions>
block. Mappings appear in the
following different places in InkML:
(一)In a <channel>
element of a
<tra
ceFormat>
, the <mapping>
element is used to describe the transformation from the values
actually produced by the device to the values recorded in the trace
data.
(二)In a <crossCoupling>
element, a mapping can
be used to specify the cross-coupling effect of one or multiple
channels on another channel.
(三)Used by a <canvasTransform>
, a mapping may
be used to specify the forward or inverse transformations between
an ink source and a canvas coordinate system.
InkML supports several types of mappings: unknown, identity,
lookup table, affine map, formula (specified using a subset of
MathML [MATHML2]) and cross product. The mapping type is indicated by the type attribute of a <mapping
>
element.
Note: If no mapping appears for a <channel>
, it
defaults to "unknown", which is safer than assuming that 'X' is
identical to the device's 'X' since some filtering or modifications
could have been applied. Furthermore, one can specify whether the
results of a mapping expression are absolute or relative to the
current data value. This is done by means of the apply
attribute. For lookup table mappings in particular, one can
determine how to interpret intermediate mapping values. This is
specified using the interpolation attribute.
<mapping>
element
<mapping xml:id="m01" type="identity" /> <channel name="X" type="decimal" units="pt" default="0"> <mapping type="identity"/> </channel>They are used, for example, to define a
<traceFormat>
channel that reports the exact
data that is recorded by a corresponding device channel, with no
filtering or transformation.
<mapping>
elements, each giving values for one
or more of the coordinates. This allows a multivariate mapping to
compute the different coordinate results according to the most
convenient means. For example, spatial coordinates may be
transformed using an affine map, button states by lookup tables,
and color coordinates using formulas.
<table>
element
containing rows of values separated by commas.
<aff
ine>
element specifying an affine
transformation (u ↦ M u + b) from
n source values to mtarget values. All of the source
and target values must be of the same type, either integer or real
(decimal or float). A matrix Mcontaining only the values 0,
1 and -1 may be used to perform arbitrary permutation and
reflection of coordinates. If the affine map computes a real number
for an integer coordinate, then the value is rounded to the nearest
integer.
<b
ind>
element.
●Arithmetic: plus, minus, times, divide, quotient, rem,
power, root, min, max, abs, floor, ceiling
●Elementary classical functions: sin, cos, tan, arcsin,
arccos, arctan, exp, ln, log
●Logic: and, or, xor, not
●Relations: eq, neq, gt, lt, geq, leq
●Operator application: apply
This is a subset has been selected to provide expressions
suitable for scalar functions on integers, real numbers and boolean
values. A number of restrictions apply:
●The only elements permitted within the
<mathml:math>
element are those in the above
list.
●The content of <ci>
and
<cn>
elements is restricted to be text. In
particular, Presentation MathML markup is not allowed.
●The only attribute that is recognized is the type
attribute on the <cn>
element. The type
attribute may take the values integer,
realorrational. Other attributes may be
given on elements, but they are ignored.
●All intermediate expressions must evaluate to an integer, real or double
value.
●Elements of the arithmetic, elementary classical functions,
logic and relations categories above may appear only as the first
child of an <apply>
element.
The content of The arithmetic operators return values whose type
depends on the type of the arguments. The logical operators and
relations return boolean values. The elementary functions return
real values.
Example: The following mapping converts from polar to
rectangular coordinates.
<mapping type="product"> <mapping type="mathml"> <bind target="X"/> <bind source="VR" variable="r"/> <bind source="VTh" variable="theta"/> <math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <times/> <ci>r</ci> <apply> <cos/> <ci>theta</ci> </apply> </apply> </math> </mapping> <mapping type="mathml"> <bind target="Y"/> <bind source="VR" variable="r"/> <bind source="VTh" variable="theta"/> <math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <times/> <ci>r</ci> <apply> <sin/> <ci>theta</ci> </apply> </apply> </math> </mapping> </mapping>
<bind>
element
<bind>
element is provided for binding
channels to entities (variable names, lookup table columns) within
a mapping, and thus it supports the reuse of predefined mappings.
For each type of mapping, the relevant bindings can be expressed by
the combined usage of the <bind>
element's
attributes, which are source, target, column
and variable.
For an identity mapping (type="identity"), if the source
channel has a different name than the channel being defined, this
can be specified using a <bind>
element with a
source attribute. In the following markup, the
<traceForma
t>
channel X contains unmanipulated
data from the device's devX channel. When the mapping
type is an identity mapping, the <bind
>
element
source attribute is required, and the other
attributes target, column, and
variable must not be present.
<channel name="X"> <mapping type="identity"> <bind source="devX"/> </mapping> </channel>Within a mapping formula (type="mathml"), the variable names in the formula need to be bound to particular channel names. This is specified using a combination of source and variable attributes for binding inputs of the formula, and target and variable for the output of the formula. This is useful if the same mapping formula is to be reused across multiple channels, like X and Y for example. When the mapping type is an mathml mapping the column attribute for the
<bind>
element must not be present.
<mapping xml:id="m06" type="mathml"> <bind target="X" variable="Q" /> <math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <plus/> <ci>Q</ci> <cn>10</cn> </apply> </math> </mapping>The example shown above means that the channel X is referred to by the variable name Q in the mapping expression "Q+10". For a lookup table (type="table"), each index column must be bound to the channel that provides the input for the lookup operation. This is done with a
<bind>
element
that specifies source and column attributes.
Similarly, each value column must be bound to the channel that
receives the output of the lookup. Its <bind>
element specifies target and column. When
the mapping type is a lookup mapping the variable
attribute for the <bind>
element must not be
present.
The following example indicates assignments of channels to
columns. It means that values for the channels OTx and P are used
to look up the value of the cross-coupling for channel X in the
table given by the mapping below:
<mapping xml:id="m07" type="table"> <bind target="X" column="1"/> <bind source="OTx" column="2"/> <bind source="P" column="3"/> <table apply="relative" interpolation="floor"> 10 45 512, 9 45 400, 8 45 372, 7 45 418, 10 50 510, 9 50 403, 8 50 302, 7 50 407, 10 55 512, 9 55 410, 8 55 303, 7 55 405, 10 60 512, 9 60 420, 8 60 355, 7 60 401, </table> </mapping>
<table>
element
ta
ble
element.
Required:no
apply = "absolute" | "relative"
Specifies whether the mapping values are used
from the table/formula, or whether this table/formula needs to be
added to the current data value.
Required: no, Default: absolute
interpolation = "floor" | "middle" | "ceiling" | "linear" |
"cubic"
Specifies the interpolation between discrete
mapping values defined by a lookup table.
Required: no, Default: "linear"
<table>
gives a set of points for a
mapping. The points are given as comma-separated rows. Each row
must have the same number of entries. The final row may optionally
be followed by a comma. Each row in the table represents a value of
the function at one point. Which columns represent the argument(s)
and which the result(s) is determined by <bind>
elements.
The entries in the table may either be all numerical or all
boolean. They may be derived empirically, by measuring properties
of a device, calculated to provide efficient approximation to a
numerical function, or give an exhaustive enumeration of values of
a function over a finite set of values.
Example:
The following example means that X is a function of OE, given by
a lookup table. The value "relative" for the apply, means
the table gives an amount to increase X.
<channel name="X"...> ... <mapping xml:id="m03" type="table"> <bind source="OE"/> <bind target="X"/> <table apply="relative" interpolation="floor"> 45 10, 50 9, 55 8, 60 7 </table> </mapping> ... </channel>Tables may have more than two columns, with some of them (the source columns) determining others (the target columns). If there is more than one source column, then all possible combinations of source values must be given. For example, if there are two source columns with one having 3 distinct values and the other having 5 distinct values, then the table must have 15 rows. The value of the interpolation attribute defines the behavior for indices that don't appear in a numerical table. The following summarizes the behavior of the above table for the various values of interpolation:
"floor" | The value is determined by rounding all source variables down
to the nearest specified value.
X += 10 if 45 ≤ OE < 50, X += 9 if 50 ≤ OE < 55, ... |
---|---|
"middle" | The value is constant on regions whose boundaries are mid-way
between the given source values.
X += 10 if 45 ≤ OE < 47.5, X += 9 if 47.5 ≤ OE < 52.5, ... |
"ceiling" | The value is determined by rounding all source variables up to
the nearest specified value.
X += 10 if OE ≤ 45, X += 9 if 45 < OE ≤ 50, ... |
"linear" | Piece-wise linear interpolation. |
"cubic" | Interpolation by cubic splines. This option may be used only for univariate mappings and requires the table have at least 4 points. |
<affine>
element
<a
ffine>
element.
Required:no
<affine>
element provides the entries for
an affine mapping from nsource values to mtarget
values. An affine mapping consists of a linear transformation
(multiplication by a matrix) and a shift (adding a vector). The
content of the <affine>
element is text giving a
m comma-separated rows of n+1 numbers each. The final
row may optionally be followed by a comma. The first n
columns specify an m ×n matrix M, and the last column
gives a vector bof length m. If uis the
source vector of ncoordinates, then v = M u +
b is the target vector of mcoordinates.
The following is an example of an affine mapping using an
<affine
>
element to describe the transform (X,
Y) ↦ (-Y, X+200).
<mapping xml:id="m01" type="affine"> <bind target="X" /> <bind target="Y" /> <affine> 0 -1 0, 1 0 200, </affine> </mapping>
<definitions>
element
<definitions>
element is a container
which is used to define reusable content. The definitions within a
<definitions>
block can be referenced by other
elements using the appropriate syntax. Content within a
<definitions>
block has no impact on the
interpretation of traces, unless referenced from outside the
<definitions>
block. In order to allow them to
be referenced, elements within a <definitions>
block must include an id; attribute. Therefore, an element
which is defined inside a <definitions>
without
an id, or that is never referenced, serves no purpose.
One of the primary uses of <defi
nitions>
is
to define contextual information. In particular, the elements
<brush>
, <canvas>
,
<canva
sTransform>
, <context>
,
<inkSourc
e>
, <mapping>
,
<timestamp>
and <t
raceFormat>
may be given inside a <definitions>
. These may
be referenced from other elements by the attributes
brushRef, canvasRef, canvasTransformRef,
contextRef, inkSourceRef, mappingRef,
timestampRef and traceFormatRef, respectively.
Timestamps may also be referenced by the respectTo attribute
of the <channel>
element.
Another use of <definitions>
is to define
digital ink traces for later reference. These may be given by
<trace>
, <traceGroup>
or<tra
ceView>
. These are not considered part of
the ink data to be handled by the application until they are
referenced from other elements (outside the
<definitions>
) by a traceDataRef
attribute. This is useful in archival applications.
The following simple example illustrates usage of the
<definition
s>
element.
<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>More details on the usage of the
<definitions>
element are provided in the Archival Applications section.
<annotatio
n>
and
<annotationXML>
, modeled after the corresponding
elements in MathML. However since annotations are typically
application-specific, InkML does not attempt to prescribe the
contents of these elements. Since the contents of
<annotation>
or<annotationXML>
elements are application
defined, implementers should use them with care and remain aware
that other implementations may ignore them or fail to round-trip
unrecognized annotations.
<annotation>
element
<annotation>
element provides a mechanism
for inserting simple textual descriptions in the ink markup. This
may be used for multiple purposes. For instance, the text contained
in the <annotat
ion>
may include additional
information provided by the user generating InkML, and may be
displayed by an InkML consumer rendering a graphical representation
of traces. Or it may be used for the indication of metadata such as
the writer, the writing instrument. Another important potential
application is the semantic tagging of traces.
<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>For semantic tagging, one of the common types of
<annotation>
is "contentCategory", which
describes at a basic level the category of content that the traces
represent; e.g., "Text/English", "Drawing", "Math", "Music". Such
categories are useful for general data identification purposes, and
may be essential for selecting data to train handwriting
recognizers in different problem domains.
Although largely application-defined, a number of likely, common
categories are suggested below.
●Text/<language>[/<script>][/<sub-category>]
(e.g., Text/jpn/Kanji, Text/en/SSN)
●Drawing[/<sub-category>] (e.g., Drawing/Sketch,
Drawing/Diagram)
●Math
●Music
●Chemistry[<sub-category>]
The language specification may be made using any of the language
identifiers specified in ISO 639, using 2-letter codes, 3-letter
codes, or country names. Some text may also require a script
specification (such as Kanji, Katakana, or Hiragana) in addition to
the language.
For some applications it may be useful to provide additional
sub-categories defining the type of the data. For example, some
suggested sub-categories for Text include:
●SSN (Social Security Number)
●Phone
●Date
●Time
●Currency
●URL
Suggested possible sub-categories for Drawing are:
●Sketch (Not suitable for geometric clean-up)
●Diagram (Suitable for geometric clean-up)
<annotationXML>
element
<annotationX
ML>
element or may be referred to by a href
attribute, but
not both. If several annotations are desired, several
<annotationXML>
elements should be given.
When annotations of a parent node include the content of the
annotations of the child nodes, then one should consider using
<annot
ationXML>
annotations on the children with
href
attributes referring to sub-trees of the parents
annotation in order to maintain linear space complexity in the
annotations.
<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>If it were not for the sharing of the substructure of the attribute XML data, then each attribute word would be repeated three times (as a word, in a paragraph, and in a chapter), each paragraph would be repeated twice, etc.
Dimension | Unit | Interpretation |
---|---|---|
length | m | meters |
cm | centimeters | |
mm | millimeters | |
in | inches | |
pt | points (1pt = 1/72 in) | |
pc | picas (1pc = 1/22 pt) | |
em | ems, the width of a letter "M" in a notional normal size | |
ex | exs, the height of a letter "x" in a notional normal size | |
time | s | seconds |
ms | milliseconds | |
mass | kg | kilograms |
g | grams | |
mg | milligrams | |
force | N | Newtons |
angle | deg | degrees |
rad | radians | |
all | % | percentage, expressed as a fraction (1.0 = 100%) relative to max-min |
dev | quanta relative to a device resolution. This can correspond to pixels, force levels, clock ticks, etc. |
unitExpr ::= unit | "1" "/" unit | unitExpr "/" unit | unitExpr "*" unit unitPrimitive ::= unit | "(" unitExpr ")" unit ::= one of the units from the table above, with the exception of em, ex, % and dev.Other units are permitted, but need not be recognized by a compliant application.
<
definitions>
elements and are assigned
identifiers using the id attribute. References to defined elements
are made using the corresponding brushRef,
traceFormatRef, and contextRef attributes. This is
illustrated in the following example:
<definitions> <brush xml:id="penA"/> <brush xml:id="penB"/> <traceFormat xml:id="fmt1"> <channel name="X" type="integer"/> <channel name="Y" type="integer"/> <channel name="Z" type="integer"/> </traceFormat> <canvas xml:id="canvasA"> <traceFormat> <channel name="X" type="decimal" min="0" max="200" units="mm"/> <channel name="Y" type="decimal" min="0" max="150" units="mm"/> </traceFormat> </canvas> <canvasTransform xml:id="trans1"> <mapping type="affine">1 0 0 0,0 1 0 0</mapping> </canvasTransform> <canvasTransform xml:id="trans2"> <mapping type="affine">2 0 0 0,0 -2 0 0</mapping> </canvasTransform> <context xml:id="context1" canvasRef="#canvasA" canvasTransformRef="#trans1" traceFormatRef="#fmt1" brushRef="#penA"/> <context xml:id="context2" canvasRef="#canvasA" canvasTransformRef="#trans2" traceFormatRef="#fmt1" brushRef="#penB"/> </definitions>This example defines two brushes ("penA" and "penB"), a traceFormat ("fmt1"), and two contexts ("context1" and "context2") which both refer to the same canvas ("canvasA") and traceFormat ("fmt1"), but with different canvas transforms and brushes. Note the use of the brushRef, traceFormatRef, canvasRef and canvasTransformRef attributes to refer to previously defined
<brush>
,
<traceFormat>
<
canvas>
and
<canvasTransform>
elements.
Within the scope of a <definitio
ns>
element,
unspecified attributes of a <context>
element
are assumed to have their default values. The
<definitions>
block below defines "context1",
which is comprised of "canvasA" with the default canvasTransform
and traceFormat (the identity mapping and a traceFormat consisting
of decimal X-Y coordinate pairs), and "penA".
<definitions> <brush xml:id="penA"/> <context xml:id="context1" canvasRef="#canvasA" brushRef="#penA"/> </definitions>A
<context>
element can inherit and override
the values of a previously defined context by including a
contextRef attribute, so the following block defines "context2"
which shares the same canvas ("canvasA") and traceFormat (the
default format) as "context1", but has a different canvasTransform
and brush.
<definitions> <brush xml:id="penA"/> <context xml:id="context1" canvasRef="#canvasA" canvasTransformRef="#trans1"/> <context xml:id="context2" contextRef="#context1" canvasTransformRef="#trans2" brushRef="#penA"/> </definitions>Within archival ink markup, traces can either explicitly specify their context through the use of contextRef and brushRef attributes, or they can have their context provided by an enclosing traceGroup. In the following example, traces "t001" and "t003" have the context defined by "context1", while trace "t002" has a context consisting of the default canvas, canvasTransform and traceFormat, and "penA".
<trace xml:id="t001" contextRef="#context1">...</trace> <trace xml:id="t002" brushRef="#penA">...</trace> <traceGroup contextRef="#context1"> <trace xml:id="t003">...</trace> </traceGroup>Traces within a
<traceGroup>
element can also
override the context or brush specified by the traceGroup. In the
following example, traces "t001" and "t003" have their context
specified by "context1" while trace "t002" overrides the default
brush of "context1" with "penA".
<traceGroup contextRef="#context1"> <trace xml:id="t001">...</trace> <trace xml:id="t002" brushRef="#penA">...</trace> <trace xml:id="t003">...</trace> </traceGroup>A trace or traceGroup can both reference a context and override its brush, as in the following example which assigns the context specified by "context1" to traces "t001" and "t002", but with "penA" instead of the default brush.
<trace xml:id="t001" contextRef="#context1" brushRef="#penA">...</trace> <traceGroup contextRef="#context1" brushRef="#penA"> <trace xml:id="t002">...</trace> </traceGroup>In archival mode, the ink markup processor can straightforwardly determine the context for a given trace by examining only the
<de
finitions>
blocks within the markup and the
enclosing traceGroup for the trace.
<context>
elements. These may directly
contain brush, trace format and other information or which may
refer to previously seen such elements. This corresponds to an
event-driven model of ink generation, where events which result in
contextual changes map directly to elements in the markup.
The current context consists of the set of canvas,
canvasTransform, traceFormat and brush which are associated with
subsequent traces in the ink markup. Initially, the current context
contains the default canvas, an identity canvasTransform, the
default traceFormat, and a brush with no attributes. Each
<brush>
, <traceFormat>
, and
<context>
element which appears outside of a
<definitions>
element changes the current
context accordingly (elements appearing within a
<definitions>
block have no effect on the
current context, and behave as described above in the archival
section).
The appearance of a <brush>
element in the
ink markup sets the current brush attributes, leaving all other
contextual values the same. Likewise, the appearance of a
<traceFormat>
element sets the current
traceFormat, and the appearance of a <context>
element sets the current context.
Outside of a <definitions>
block, any values
which are not specified within a <context>
element are taken from the current context. For instance, the
<context>
element in the following example
changes the current brush from "penB" to "penA", leaving the
canvas, canvasTransform, and traceFormat unchanged from trace
"t001" to trace "t002". That is, each context element is taken to
inherit from the previously established context.
<brush xml:id="penA"/> <brush xml:id="penB"/> <trace xml:id="t001">...</trace> <context brushRef="#penA"/> <trace xml:id="t002">...</trace>In order to change a contextual value back to its default value, its attribute can be specified with the value "#DefaultCanvas" or "#DefaultBrush". In the following:
<context canvasRef="#canvasA" brushRef="#penA"/> <trace xml:id="t001">...</trace> <context canvasRef="#DefaultCanvas" brushRef="#DefaultBrush"/> <trace xml:id="t002">...</trace>Trace "t001" is on "canvasA" and has the brush specified by "penA", while trace "t002" is on the default canvas and has the default brush. Brushes, traceFormats, and contexts which appear outside of a
<de
finitions>
block and contain an id
attribute both set the current context and define contextual
elements which can be reused (as shown above for the brushes "penA"
and "penB"). This example:
<context xml:id="context1" canvasRef="#canvasA" canvasTransformRef="#trans1" traceFormatRef="#fmt1" brushRef="#penA"/>defines a context which can be referred to by its identifier "context1". It also sets the current context to the values specified in the
<context>
element.
A previously defined context is referenced using the
contextRef attribute of the <context>
element. For example:
<context contextRef="#context1"/>sets the current context to have the values specified by "context1". A
<context>
element can also
override values of a previously defined context by including both a
contextRef attribute and one or more of the
canvasRef, canvasTransformRef, 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 and
overrides values from a previous context can itself be reused, so
the element:
<context xml:id="context2" contextRef="#context1" brushRef="#penB"/>defines "context2" which has the same context values as "context1" except for the brush. Finally, a
<context>
element with only an id
has the effect of taking a "snapshot" of the current context which
can then be reused. The element:
<context xml:id="context3"/>defines "context3", whose values consist of the current canvasRef, canvasTransform, traceFormat, and brush at the point where the element occurs (note that since "context3" does not specify any values, the element has no effect on the current context). An advantage of the streaming style is that it is easier to express overlapping changes to the individual elements of the context. However, determining the context for a particular trace can require more computation from the ink markup processor, since the entire file may need to be scanned from the beginning in order to establish the current context at the point of the
<trace>
element.
While it is possible to wait and generate each trace as it is
completed, this can lead to considerable latency from the starting
time with long strokes. This may be avoided by
generating traces of partial strokes and using continuation
traces.
Finally, it should be noted that traces can overlap in
time. This can occur in collaborative applications with
several writers or with one user on "multi-touch" devices.
Here it is also possible to generate traces for complete strokes on
pen up, but applications may use partial strokes of limited time
duration to guarantee that a buffer restricted to a sliding time
window sees all simultaneous traces.
<ink xmlns="http://www.w3.org/2003/InkML"> ... <definitions> <brush xml:id="penA"/> <brush xml:id="penB"/> <context xml:id="context1" canvasRef="#canvas1" canvasTransformRef="#trans1" traceFormatRef="#format1"/> <context xml:id="context2" contextRef="#context1" canvasTransformRef="#trans2"/> </definitions> <traceGroup contextRef="#context1"> <trace>...</trace> ... </traceGroup> <traceGroup contextRef="#context2"> <trace>...</trace> ... </traceGroup> <traceGroup contextRef="#context2" brushRef="#penB"> <trace>...</trace> ... </traceGroup> <traceGroup contextRef="#context1" brushRef="#penB"> <trace>...</trace> ... </traceGroup> <traceGroup contextRef="#context1" brushRef="#penA"> <trace>...</trace> ... </traceGroup> </ink>Streaming
<ink xmlns="http://www.w3.org/2003/InkML"> ... <definitions> <brush xml:id="penA"/> <brush xml:id="penB"/> </definitions> <context xml:id="context1" canvasRef="#canvas1" canvasTransformRef="#trans1" traceFormatRef="#format1"/> <trace>...</trace> ... <context xml:id="context2" contextRef="#context1" canvasTransformRef="#trans2"/> <trace>...</trace> ... <context brushRef="#penB"/> <trace>...</trace> ... <context contextRef="#context1"/> <trace>...</trace> ... <context brushRef="#penA"/> <trace>...</trace> ... </ink>In the archival case, the context for each trace is simply determined by the
<trace>
element, its enclosing
traceGroup, and contextual elements defined in the
<def
initions>
block, while in the streaming
case, the context for a trace can depend on the entire sequence of
context changes up to the point of the <trace>
element.
However, the streaming case more simply expresses the changes of
context involving "penB", "context1", and "penA", whereas the
archival case requires the restatement of the unchanged values in
the successive traceGroups.
The two styles of ink markup are equally expressive, but impose
different requirements on the ink markup processor and generator.
Tools to translate from streaming to archival style might also be
of use to applications which work on stored ink markup.
<brush>
definitions, and <traceFormat> definitions
should be placed within a <definition> element and
referred to in required places such as <trace> elements.
Applications should take advantage of trace data
prefixes (' | " | *) for defining relative coordinate values.
The use of first and second order derivative coordinates can
effectively compress <trace> element data
losslessly.
Applications should make use of the 'current
context' to cache the context property values and hence reduce the
context property markups that are being sent explicitly along with
trace data.
(三)InkML transmission
Any of the usual XML protocols (StAX, SOAP, etc)
may be used to transmit InkML documents or fragments between
subprograms or distributed programs.
(四)Network streaming
Client and server applications that wish to
stream InkML should have the capability to process the data sent in
multiple fragments of InkML packets. The receipt of such
InkML fragments may progressively render on the client or
clients.
application/inkml
+xml
".
The
"application/inkml+xml
"
media type is being submitted to the IESG
for review, approval, and registration with IANA.
application
MIME subtype name:
inkml+xml
Required parameters:
None.
Optional parameters:
charset
This parameter has identical semantics to the
charset
parameter of the application/xml
media type as specified in [RFC3023] or its successor.
Encoding considerations:
By virtue of InkML content being XML, it has the same
considerations when sent as "application
/inkml+xml
" as
does XML. See RFC 3023 (or its successor), section 3.2.
Security considerations:
Several InkML instructions may cause arbitrary URIs to be
dereferenced. In this case, the security issues of [RFC3986], section 7, should be
considered.
In addition, because of the extensibility features for InkML, it
is possible that "application
/inkml+xml
" may describe
content that has security implications beyond those described here.
However, if the processor follows only the normative semantics of
this specification, this content will be ignored. Only in the case
where the processor recognizes and processes the additional
content, or where further processing of that content is dispatched
to other processors, would security issues potentially arise. And
in that case, they would fall outside the domain of this
registration document.
Interoperability considerations:
This specification describes processing semantics that dictate
behavior that must be followed when dealing with, among other
things, unrecognized elements.
Because InkML is extensible, conformant
"application/inkml+xml
" processors MAY expect that
content received is well-formed XML, but processors SHOULD NOT
assume that the content is valid InkML or expect to recognize all of
the elements and attributes in the document.
Published specification:
This media type registration is extracted from Appendix D of
the Ink Markup Language
(InkML) specification.
Additional information:
Magic number(s):
There is no single initial octet sequence that is always present
in InkML documents.
File extension(s):
InkML documents are most often identified with the extensions
".ink
" or ".inkml
".
Macintosh File Type Code(s):
TEXT
Person & email address to contact for further
information:
Kazuyuki Ashimura, <ashimura@w3.org>.
Intended usage:
COMMON
Author/Change controller:
The InkML specification is a work product of the World Wide Web
Consortium's Multimodal Interaction Working Group. The W3C has
change control over these specifications.
applic
ation/inkml+xml
",
the fragment identifier notation is exactly that for
"application/xml
", as specified in RFC 3023.