[
Lists Home |
Date Index |
Thread Index
]
[original went to the wrong place]
----- Original Message -----
From: "Michael Champion" <michaelc.champion@gmail.com>
To: <xml-dev@lists.xml.org>
Sent: Saturday, December 04, 2004 3:38 PM
Subject: Re: [xml-dev] The XML Backlash
> On Fri, 3 Dec 2004 10:34:39 -0600, Bullard, Claude L (Len)
> <len.bullard@intergraph.com> wrote:
>>
>> Are we at the emergence point of an XML backlash?
>
> I've been expecting such a backlash for about 5 years now. The
> namespaces discussion on various threads reminded me of a rant I
> indulged in when I first began to think that the complexity and
> inconsistency in the XML corpus was hopeless
> http://groups.yahoo.com/group/sml-dev/message/59 ). [the
> reference is to a DOM WG meeting during the Level 2 days]
>
> "6 -- count 'em -- SIX hours of discussion on how to resolve the mess that
> is created when parsed entities meet namespaces. And they probably took
> another six hours off my life because of the chocolate consumed to fight
> the
> depression and caffeine consumed to fight the urge to sleep. And we ended
> up deciding to essentially put up a sign saying "There Be Dragons There"
> because the problems are too complex to solve without mandating a lot
> of machinery that would serve little purpose but to present a pretty
> face on a very, very ugly mess."
>
> BUT 5 years later, XML still marches on -- it's OFF the Gartner hype
> cycle because it is so widely accepted.
> http://www4.gartner.com/DisplayDocument?doc_cd=120920 The peasants
> haven't rebelled, and I don't see many signs that they are about to.
>
> The complaints in the various postings Len forwarded are not exactly
> new, and are mainly from the equivalent of bohemian intellectuals, not
> the oppressed peasantry :-) Many are already enshrined as xml-dev
> permathreads. The "LISP could do everything XML does 30 years ago"
> argument is not new either. It is beside the point, however: for
> whatever reason, XML has become establisned as a ubiquitous standard
> and has got the network effect working in its favor, the other
> possibilities such as LISP and ASN.1 never did. Maybe we would have
> been better off if they had, but we'll never know.
>
well, I was once a strong supporter of use of s-expressions for general data
representation. at the time, I was also maintaining my own scheme
implementation.
then, I stopped using it (along with a lot of other related code), and the
issue came up: xml or s-expressions. at the time I leaned twards xml, since
I had code allready in place there.
at this point, some of the strengths of xml showed themselves...
of course, there are cases where something s-expression like would make more
sense, eg, it would likely be easier to straightforwardly map the parse
trees to a binary encoding (the bigger issue is whether or not one keeps the
typesystem, or makes their own). yes, there is an issue with s-expressions,
namely in that there is a lot more variability in some things, eg, the
syntax can vary in minor ways, the typesystems can be different, ...
one could either lock it down (spefifying the exact syntax and typesystem,
for example), or being a little looser or maybe providing a "type extension"
mechanism.
dunno.
> So will the backlash ever begin? I'm of two minds, as usual:
>
> On one hand, maybe never -- sensible people can avoid most of the
> nasty problems by just sticking to a simple, sane, subset of XML and
> the other specs. It's only the corners that have the ugly messes in
> them, and there
> are plenty of Here Be Dragons signs up that anyone who reads mailing
> lists such as this know about, and others learn about the hard way.
> Maybe in the long run the W3C or somebody will bless the sane/common
> subset and the corner cases will fade from memory.
>
dunno, maybe.
> On the other hand, maybe it's already underway. The web services
> people just quietly banished DTDs (and with them all the
> entity-related dragons) from the kingdom, and nobody but a few purists
> seriously complained. Likewise, the wireless people are quietly
> working on binary XML-like formats and may standardize on them with or
> without the W3C's imprimatur. Given the relative growth rates of
> mobile and desktop devices, it's a safe bet that the server-side folks
> will support any wireless industry XML-like standards if they get
> momentum, again with or without the W3C. It is at least plausible that
> these kinds of efforts will lead us to the point where SGML was in
> 1996, and a collaborative, sanctioned effort to create something new
> out of the lessons of XML will get traction.
>
I had just never implemented or really cared much about dtd myself.
> I wonder if there are analogous cases in the history of technolgy
> (ahem, besides SGML?) where a set of good ideas got out of control.
> If so, what happened? Did people just learn to ignore the cruft and
> stick with what worked without worrying about it? Did the mess get
> refactored back into the good ideas plus whatever was learned on the
> way ? Did the whole thing -- wheat, chaff, babies, bathwater -- get
> replaced by something else?
>
> A few possibilities to chew on:
>
> Computer languages -- clearly new ones replace older ones, stealing
> whatever good ideas they offered (although of course the old ones
> live on ... I *know* how much COBOL there is out there!). Clearly
> this falls into the "baby and bathwater both get chucked out"
> category.
>
imo, people are often too eager to replace programming languages, but, at
the same time, it is not that possible to evolve the programming language
with the app, and people feel reluctant to evolve languages over time.
also, people often interact fairly directly with programming languages, and
spend a lot of time with them.
in effect, each becomes a kind of snapshot to be later replaced.
> The Intel computer architecture. It looked pretty hideous the last I
> even tried to deal with assembly level programming in the late '80s
> ... did that horrible 16-bit segmented addressing mode stuff get
> factored out, hidden away, quietly ignored, or what? My guess is that
> this falls into the "mess gets gradually refactored" category. ???
>
segmentation has graudually faded away, going from a basic feature (real
mode) to a more abstracted feature (16 bit protected mode) to a more obscure
feature (32 bit protected mode) to something almost forgotten by the
hardware (x86-64).
even in an os kernel, one doesn't need more than a few segments (ring 0 32
bit code/data, ring 3 32 bit code/data, ring 0 16 bit code/data, a tss
segment, ...). afterwards, it is just an occasional annoyance, and app
programmers can all but forget about segmentation.
typically, the 32 bit segments were just base=0, limit=0xFFFFFFFF anyways.
in x86-64, I guess a lot of the contents of the gdt entries are ignored, in
effect the cpu is using the flat memory model.
sadly, I have not looked into the details that much, which is lame.
> Windows APIs -- This might be a particularly good historical example
> to learn from ... Obviously the early versions had serious
> limitations, but it was not economically feasible to simply kill them
> off and move on. As I understand it there's an ongoing struggle
> between the need not to break existing applications and to move
> forward in a better direction. I'm not sure what the lesson for XML
> is, other than "whatever you do will make SOME substantial group of
> people VERY mad". I guess Windows exhibits all three categories:
> Users learn to avoid the dragons, some parts of MS work on refactoring
> things without breaking too many legacy apps, and some parts of MS
> proceed forward with new APIs that don't attempt to maintain
> compatibility ???
>
yes.
I am feeling unsure if when I sart using an athlon-64 in my 16 bit crap will
just break, or if I will be able to continue using it...
> Anyway, there doesn't seem to be a clear pattern ... but the one thing
> that XML lacks that the Intel and Windows examples had was somebody
> taking the lead on the refactoring. The sense I get from most
> discussions with XML geeks is "we're stuck with the whole thing ; we
> can't ever do anything that will break ANYBODY" rather than "we have
> to map out a migration path that gets us to a better place with the
> least disruption." I much prefer the latter. Some early adopters
> will suffer if the bits of XML that turned out to be bad ideas are
> factored out, but in the long run we will all be better off. The
> alternative isn't the XML status quo, it's fighting the backlash and
> losing.
>
dunno.
I like the idea of dropping some things from xml, but will probably disagree
with others about what exactly...
eg: imo, I could live with both dtd's and entities dropped, and maybe
doctype as well.
cdata is rather ugly, but the ugly syntax for cdata at least leads to a low
probability escape sequence. I, however, don't particularly like the way in
which the escape sequence is escaped, but this is an unimportant issue.
|
