Re: XML and InkML

Hi Simon,

Thanks for the feedback. Below is my view of the problem (not the WG's):

"Simon St.Laurent" <simonstl@simonstl.com> wrote:

> 1) Defining the non-XML trace markup and its specification tools in a
> separate specification. If you're going to define such a vocabulary,
> effectively a new data type, at least provide it a definition (and a
> name) which is easily reused by other processors.  InkML can then be a
> wrapper format for that data, supporting metadata about those traces.

Interesting suggestion, but where do you draw the line?

At one end of the spectrum, my new data type is just defined as
"(char?  number+)+" and the meaning of 'char' is left to the markup
using this datatype. This covers pretty much InkML traces and SVG
paths, and we're done, no need for a separate spec.

At the other end, you have "List of Numbers Language", a spec that
describes serialisations of numerical samples. Needless to say, people
like managing numbers in many different ways, which probably makes the
requirements daunting:

- value datatype and format
- first/second/nth order difference
- multiple channels, some with optional values.
- moveto/lineto/closepath
- interpolation (bezier, bsplines, other curves, in any dimension and in 
  any degree)
- compression
- more, proably

A bit scary for the ink subgroup of the multimodal interaction wg, if
you ask me.

My preference lies somewhere in between, but leans towards the first end.
I think that the format should just be: 

num num num num num;    <!-- 1 sample of 5 channels -->
num num num   * num;    <!-- * is an unspecified value -->

and then you gzip the whole document, and I suspect that compresses
just as well as using deltas. But ink device specialists will perhaps
prove me wrong and tell me that gzip is too costly. Then I'm ready
to accept deltas this way:

num  num 'num "num num;
num "num  num    * num;

I also like this simple scheme because I can easily parse it in XSLT, while 
"1125 18432'23'43"7"-8 3-5+7  -3+6+2+6 8+3+6:T;+2+4:*T;+3+6+3-6:FF;"
is making my stylesheet horrible.

> 2) Providing an XML representation of InkML in addition to the compact
> form.  Even if most InkML-only tools work with the information in the
> compact form, a more verbose representation will make it much easier for
> other applications to consume the information provided by InkML.

I'm hoping that my suggestion above will be popular enough that we can
avoid the two syntaxes...

Cheers,

Max.

Received on Saturday, 23 August 2003 15:36:38 UTC