[
Lists Home |
Date Index |
Thread Index
]
ricko@allette.com.au (Rick Jelliffe) writes:
>Let us imagine four constraints:
> 1) InkML must be text
> 2) InkML must be terse (faster parsing, less space)
> 3) InkML must be embeddable as part of an XML document
> 4) InkML objects must be annotatable and extendible using XML (or
>XML-ish) mechanisms
Sorry, Rick, but while these constraints may exist in the committee's
minds, they never bother to justify their concrete decisions on such
grounds. They appear nowhere in the spec [1] or in the requirements
[2]. Section 5 of the requirements regarding PDAs is the closest I can
find, but such justifications hardly kept Tiny SVG from using markup for
the bulk of its contents.
On #4, perhaps it would have made sense to define the trace language as
a separate language and the rest of InkML as a wrapper, but that isn't
what the committee chose to do. The traces themselves are not in fact
extensible, only annotable.
I heartily encourage developers to use lexical approaches which aren't
XML inside of XML contexts - it helps with human-accessibility, among
other factors. At the same time, once you get beyond a certain ratio of
markup to encoded content, it makes a mockery of using XML in the first
place - especially when the encoded content is this opaque.
[1] - http://www.w3.org/TR/2003/WD-InkML-20030806/
[2] - http://www.w3.org/TR/inkreqs/
|
