[
Lists Home |
Date Index |
Thread Index
]
mc@xegesis.org (Mike Champion) writes:
>> That's a lot of why I'm talking less and less about XML and more and
>> more about markup.
>
>Yup. Well, I don't blame you ... and I hear similar frustrations from
>the "data" side about the constraints that XML syntax handling
>imposes. The "data" and "sevices" people with their infosets and
>datatypes and requirements for millisecond-timeframe XML instance
>processing certainly create challenges. On balance, I would prefer
>to preserve and refine what is common in the center so that APIs,
>schema languages, query languages, etc. can be shared across both
>communities. But I certainly respect the hypothesis that the path of
>least resistance is for the communities to fork.
I think that forking is both necessary and useful, and it might in fact
let the two communities communicate better both internally and with each
other.
While XML is capable of operating as a data format, it was never
designed to meet the kinds of criteria that data-oriented developers
typically demand, as you note above. The kinds of solutions that
frequently seem obvious to data-oriented developers seem
counter-intuitive or outright broken to me, even when I'm working on
"strictly data" applications of XML.
Right now, it seems that most XML spec development is in the hands of
people with a data-centric mindset, intent on shoveling strong typing,
envelopes, and global identifiers into every spec they can. The kindest
words they seem to have for those of us who think that's completely
inappropriate to markup are "you don't have to use it. Now get out of
the way."
(The other dominant faction at the W3C seems to believe that slapping a
URI reference on everything directly or indirectly is the best way to
make things better, another perspective that seems senseless but which
is even harder to avoid.)
Let's get the hell out of each other's ways. The sooner, the better,
preferably in an orderly way, with well-established bridges.
A flexible set of tools that lets the must-have-typed-data-as-fast-
as-possible folks do their work without the overhead of XML seems like a
good idea on its own merits - preferably a toolset standardized in an
open process without intellectual property constraints and with multiple
interoperable implementations. A clearly-defined process for
converting between that format and an XML format, even a somewhat
grotesque XML format, would be even better. (Think of it as a filter
you can insert between the data and an XML parser, letting you treat it
as XML even though it ain't.)
The ASN.1 folks have been doing some work in this direction, though I
have to confess that I still find their work difficult to understand,
much less write anything resembling a parser for. The W3C seems at the
moment to be pushing for XML throughout their specs, without much direct
consideration of alternatives. The Infoset seems to be the point that
people who want something more keep pushing, though with limited
success.
>That may well be what's going to happen, for a lot of reasons --
>nobody can get passionate about muddy compromises, so the center
>often does not hold.
I see the current everything-piled-into-XML as a "muddy compromise", and
suspect that the weight of that compromise may be what crushes the
center eventually.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
