[
Lists Home |
Date Index |
Thread Index
]
Perhaps, but it seems that we as XML application language
designers and members of working groups should take on
the challenge to reuse as much pre-existing productions
as make sense to the particular language. Various means
of doing this were attempted in the CALS days and it is
quite politically hard given say a vendor rooting for
their own xmlized format to accept the new markup. On
the other hand, as Tim said in his article, over time
the semantic of <ul> has become common and the expectation
of any XML author is as well.
I think there are some different issues that tend to
cleave along the lines of rendering and data languages
(say document if you like). The rendering XML
application specifications should provide strong abstract
object models because behavioral fidelity is a
requirement. The data languages do not need the
abstract object model in all cases (some may), but
they should strive to share the syntax model for
productions as much as possible because that will
save some effort for authors and implementors.
One can argue if attributes or elements are better.
One can argue if verboseness matters (and the
graphics apps argue that a lot), but it seems
we can and should attempt to work out commonality
of production as simple as XYZ coordinates, paragraphs,
lists, and so on.
Lists of numbers are common, BTW. X3D has them too.
But when SVG and X3D finally do merge in a meaningful
fashion, it will be painful to work in namespaces where
each one has a different way to specify coordinates.
len
-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Thursday, August 21, 2003 8:48 AM
To: 'xml-dev@lists.xml.org'
Subject: Re: [xml-dev] InkML
clbullar@ingr.com (Bullard, Claude L (Len)) writes:
>Good call, Elliotte, on the con Leche review of the
>InkML first draft.
http://www.ibiblio.org/xml/
I can live with micro-parsing when there's a demonstrable benefit,
typically to humans, but lists of numbers?
<trace>
10 0 9 14 8 28 7 42 6 56 6 70 8 84 8 98 8 112 9 126 10 140
13 154 14 168 17 182 18 188 23 174 30 160 38 147 49 135
58 124 72 121 77 135 80 149 82 163 84 177 87 191 93 205
</trace>
Wow. Amazingly ingenious.
Maybe the TAG should take up the issue of sensible markup usage for W3C
specs rather than arguing about URIs. Maybe that's building materials,
not architecture, but it seems like architects should be paying
attention to the materials they're using as well.
|
