[
Lists Home |
Date Index |
Thread Index
]
From: "Jonathan Borden" <jborden@attbi.com>
> I am all for pluggable type libraries. Aside from that, any fact that XML
> is verbose is not something that we've been too concerned with. (we've all
> heard this before).
And, as a result, it is very hard to make tools for XML.
Take that <position> example. A way to declare the rules to go from a lexical
space to a value space (e.g. using grammars, picturess or whatever) would
allow a nice user interface where the user types an idiomatic entry and the GUI
converts it to markup. Just as much, it would allow someone with a simple text editor
to enter the values and validate. (In some cases, the rules might be reverseable and help
rendering too.) No losers, as far as I can see.
That XML removed out SGML's facilities for parsing text and implying
tags, does not mean that it is not appropriate or practical functionality for some
other layer to have some system of declarations. (As XML Schemas
found out with their derivation by lists and unions.)
> Yes and the corrollary I'd add is that any short term benefits one might get
> with compact syntaxes is usually lost on the long term problem of dealing
> with such syntaxes. Time to move onto the harder problems of assigning
> semantics to the syntax (e.g. business rules).
Would you include COBOL pictures in that? They seem to have been
one of the most successful and long term syntax-defining techniques.
"Let's get on to business rules" is irrelevent to people in publishing
who do not have business rules in their data in that way.
Otherwise, we will be left with complex tools but no data, because the
stage of getting from what people want to read and write and the
particular types that committees have decided on has a standards
gap. In the data capture world, GOMS and low-training are still king.
Complex data values should not be sniffed at.
Here is an example from
http://www.w3.org/TR/SVG11/paths.html
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
<svg width="12cm" height="5.25cm" viewBox="0 0 1200 400"
xmlns="http://www.w3.org/2000/svg"; version="1.1">
<title>Example arcs01 - arc commands in path data</title>
<desc>Picture of a pie chart with two pie wedges and
a picture of a line with arc blips</desc>
<rect x="1" y="1" width="1198" height="398"
fill="none" stroke="blue" stroke-width="1" />
<path d="M300,200 h-150 a150,150 0 1,0 150,-150 z"
fill="red" stroke="blue" stroke-width="5" />
<path d="M275,175 v-150 a150,150 0 0,0 -150,150 z"
fill="yellow" stroke="blue" stroke-width="5" />
<path d="M600,350 l 50,-25
a25,25 -30 0,1 50,-25 l 50,-25
a25,50 -30 0,1 50,-25 l 50,-25
a25,75 -30 0,1 50,-25 l 50,-25
a25,100 -30 0,1 50,-25 l 50,-25"
fill="none" stroke="red" stroke-width="5" />
</svg>
Oops, did someone forget to tell them that terseness is of minimal
importance? Or is it that there is a sweet spot at which
point specialist and idiomatic notations (paths, URLs, dates, positions,
Xpaths, styles, measurements, etc) are appropriate?
Indeed, is it positively bad for readability (and therefore
maintainability, comprehensability, cheap-tool-ability) to have no
embedded notations for complex values?
No one (except maybe the YAML people :-) would be saying you
must never use XML! But I don't believe that most people buy
into the idea that all structures should be marked up regardless
of idiom or verbosity.
Cheers
Rick
|
