Re: XML and InkML

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

> 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.

You make a valid point, although I think that it's more valid about
the parsing than about the readability. If a human is going to read
the file, I suppose it'll be for debugging and you can expect that
they know enough of the format that it makes little difference.

> This is a long and old thread.  W3C XML Schema's datatypes are a
> disaster for many reasons.

Let's keep that permathread to xml-dev. My argument was only about the
lexical representation. I could very well have wrote about
xsd:decimal, which requires parsing according to ISO822 (or something) rules.

> 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.

I still think that we want only just one syntax, whether it's XML
or a lexical one. 

> 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.

CSS has its own syntax for reasons that don't apply to InkML. And the
style attribute (which some people still regard as a bad thing) is
merely a convenience.

> On the bright side, it's human-readable, and software for processing
> it is very widely available.  InkML has neither of those advantages.

Unlike HTML, SVG and others, InkML is not at all meant to be
hand-written or even read by humans, apart for debugging purposes. And
developers could claim that packing trace data into an element using a
compact syntax makes the rest of the markup more visible (because
whatever the syntax, a human can't make much of trace data, and no,
there isn't traces in the syntax). Also, I'm very much afraid of the
size a full-markup DOM would have. And of course InkML isn't widely
available. CSS wasn't available when it was developed, that didn't
stop it having an non-SGML syntax.

> it's a lousy way to share information about the traces with a wider
> variety of processors.

Most processors (with the exception of converters) that will work on
InkML are going to implement much more than just trace data
parsing. Why wouldn't trace data parsing be a (small) part of that
general application dependent process?

> 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.

It's not about vendor dependence, it's about application dependence.
If you did mean application dependence, then fair enough, we're back
to the original question, and again I'll ask the WG that they consider
your arguments in our upcoming discussions.

Cheers,

Max.

Received on Thursday, 28 August 2003 06:11:29 UTC