Re: InkML <trace> element; why require a BNF parser in addition to an XML parser?

Hi Steve,

Steven Brown <swbrown@ucsd.edu> wrote:

> The <trace> element in InkML seems to abandon XML in favor of a custom
> BNF parser, I assume to try and save space.  I was wondering, what is
> the rationale behind this decision?

to try and save space, yes, but especially to have a manageable DOM,
which otherwise would have hundreds of sibling point nodes. SVG made a
similar decision and since then I don't think anyone's complained about
the extra parser, or at least enough that the group reconsidered it.
This doesn't mean that we would never change our syntax, we might consider
an alternative full XML syntax if we had really good reasons to. 

The next working draft will probably include changes in the trace syntax,
which might make the extra parsing easier.

Your point about extensibility is interesting, though. The current
mechanism allows a certain amount of extensibility through the
traceformat element, and I think that the actual contents of the trace
element are basic enough that it isn't obvious that there's a need to
extend them. Or perhaps the datatypes, allowing text and durations,
for instance. But I can't think of a use case for that off the top of
my head, so you're welcome to send in use cases.

A similar discussion came up a year ago on this list, actually. See
http://lists.w3.org/Archives/Public/www-multimodal/2003Aug/0003.html

Thanks for your comment,

Max.

Received on Thursday, 29 July 2004 05:52:38 UTC