Re: XML and InkML

mf@w3.org (Max Froumentin) writes:
>"Simon St.Laurent" <simonstl@simonstl.com> wrote:
>
>>>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.
>>
>> Could I have a full example of this?  It doesn't look substantially
>> easier to parse to me.  
>
>It is because there's only one separator that's there all the time.
>Compare "1 2 3 4 5 6 7 8" and "1 2; 3 4; 5 6; 7 8"
>
>Also, I would favour mandatory whitespace between channels, so we
>avoid
>
>1-2+3 4'-5'6"7"8
>
>Meaning that each bunch of channel samples is tokenized using ';' as
>separator and each channel is plit by ' '

I still have no way to tell what the channels are except on a format by
format basis.  It does basically nothing for human readability and only
simplfies the parse slightly.

>> I also suspect that you'll need to define an XML vocabulary for
>> interchange regardless, as this still requires a separate parsing
>> process.
>
>Maybe, and I hope the WG will consider it. But I think that it's the
>complexity of the syntax that will decide. Do you (or Elliotte) think
>that XML Schema should have made dateTime a complex type on the
>grounds that it's lexical representation requires a separate parsing
>process?

This is a long and old thread.  W3C XML Schema's datatypes are a
disaster for many reasons, and the dates and times are probably the most
radioactive corner of that wreckage.  My primary objection to them is
their inflexibility - humans and ISO dates are not a good combination.

I don't object to lexical parsing per se - see, for example:

http://simonstl.com/projects/fragment/

I do think, however, that such types deserve to have an XML
representation (which Reg Frag is designed to provide), and that we need
to think very carefully before creating lexical types.  

The CSS style attribute is probably the case most frequently discussed.
On the unfortunate side, it requires a separate parse, sometimes has
multiple layers of depth, and puts multiple layers of content into a
single attribute.  On the bright side, it's human-readable, and software
for processing it is very widely available.  InkML has neither of those
advantages.

It seems to me that InkML is really a tiny wrapper around
vendor-dependent trace formats.  I suppose that's useful if that's what
you want to store, but it's a lousy way to share information about the
traces with a wider variety of processors.  I have a hard time seeing
why the W3C should care about vendor-dependent formats, while making ink
traces readily processable by many applications - without the need for
extra code libraries - seems like a more congenial project.

Received on Monday, 25 August 2003 20:48:06 UTC