The W3C Multimodal Interaction Working Group has published the second public working draft of the Ink Markup Language. According to the abstract,
The Ink Markup Language serves as the data format for representing ink entered with an electronic pen or stylus. The markup allows for the input and processing of handwriting, gestures, sketches, music and other notational languages in Web-based (and non Web-based) applications. It provides a common format for the exchange of ink data between components such as handwriting and gesture recognizers, signature verifiers, and other ink-aware modules.
The following example of writing the word "hello" in InkML is given in the spec:
<ink>
<trace>
10 0 9 14 8 28 7 42 6 56 6 70 8 84 8 98 8 112 9 126 10 140
13 154 14 168 17 182 18 188 23 174 30 160 38 147 49 135
58 124 72 121 77 135 80 149 82 163 84 177 87 191 93 205
</trace>
<trace>
130 155 144 159 158 160 170 154 179 143 179 129 166 125
152 128 140 136 131 149 126 163 124 177 128 190 137 200
150 208 163 210 178 208 192 201 205 192 214 180
</trace>
<trace>
227 50 226 64 225 78 227 92 228 106 228 120 229 134
230 148 234 162 235 176 238 190 241 204
</trace>
<trace>
282 45 281 59 284 73 285 87 287 101 288 115 290 129
291 143 294 157 294 171 294 185 296 199 300 213
</trace>
<trace>
366 130 359 143 354 157 349 171 352 185 359 197
371 204 385 205 398 202 408 191 413 177 413 163
405 150 392 143 378 141 365 150
</trace>
</ink><sarcasm>Gee, that's not the least bit opaque.</sarcasm>. This looks like the SVG mistake all over again. I wrote about this in Item 11 of Effective XML, "Make Structure Explicit through Markup.". Thr right way to solve this problem is something like this:
<ink>
<trace>
<coordinate><x>10</x> <y>0</y></coordinate>
<coordinate><x>9</x> <y>14</y></coordinate>
<coordinate><x>8</x> <y>28</y></coordinate>
<coordinate><x>7</x> <y>42</y></coordinate>
<coordinate><x>6</x> <y>56</y></coordinate>
<coordinate><x>6</x> <y>70</y></coordinate>
<coordinate><x>8</x> <y>84</y></coordinate>
<coordinate><x>8</x> <y>98</y></coordinate>
<coordinate><x>8</x> <y>112</y></coordinate>
<coordinate><x>9</x> <y>26</y></coordinate>
<coordinate><x>10</x> <y>140</y></coordinate>
<coordinate><x>13</x> <y>154</y></coordinate>
<coordinate><x>14</x> <y>168</y></coordinate>
<coordinate><x>17</x> <y>182</y></coordinate>
<coordinate><x>18</x> <y>188</y></coordinate>
<coordinate><x>23</x> <y>174</y></coordinate>
<coordinate><x>30 </x> <y>60</y></coordinate>
<coordinate><x>38</x> <y>147</y></coordinate>
<coordinate><x>49</x> <y>135</y></coordinate>
<coordinate><x>58</x> <y>124</y></coordinate>
<coordinate><x>72 </x> <y>21</y></coordinate>
<coordinate><x>77</x> <y>135</y></coordinate>
<coordinate><x>80</x> <y>149</y></coordinate>
<coordinate><x>82</x> <y>163</y></coordinate>
<coordinate><x>84</x> <y>177</y></coordinate>
<coordinate><x>87</x> <y>191</y></coordinate>
<coordinate><x>93</x> <y>205</y></coordinate>
</trace>
</ink>
That's more verbose, but it's also much clearer. It would let
the data be extracted with standard XML tools rather than
requiring each user to write their own micro-parser for the
trace elements. If InkML really can't afford to
actually markup the x and y coordinates as x and y
coordinates instead of raw text, then one wonders why it's
using XML at all?