[
Lists Home |
Date Index |
Thread Index
]
[permathread]
alaric@alaric-snell.com (Alaric B Snell) writes:
>It's not about "binary", it's about "typed". And although there is a
>typeless subset of XML - where no schemas or DTDs are used - there is
>a significant number of people who do use typed information of one
>kind or another. And despite they've created DTDs, XML Schema, XPath
>2, and so on, you can still do your non-constrained XML transfers of
>sequences of characters if you want to; they've not polluted it in any
>way, OK? So stop panicking, man!
I'm sorry, Alaric, but this is the classic story that's done so much to
pollute XML and turn what was once a pleasant simplfication into an
industrial-strength nightmare. That it's frequently told by people who
believe it doesn't do anything to help it.
I wish you could have been at the Extreme Markup Languages conference
when Jeni Tennison gave a presentation on the impact of typing on XSLT
and XPath 2.0. As C. Sperberg-McQueen summarized it, "I was watching
all these faces, all of them asking 'if Jeni Tennison can't deal with
this, how am I ever going to?'"
The impact of these technologies - all supposedly "non-polluting"
"choices" that add more "capabilities" to XML - is a dense tangle. The
most appropriate word I can come up with for it, well, begins with
"cluster".
Why have these choices made life so difficult?
I'll run down a few reasons.
1) We don't all get to choose. We don't all get to choose our tools,
and even fewer of us get to choose the data we work with. As these
things spread across the landscape, they become unavoidable.
All of the tools I write for processing XML now support namespaces.
That isn't because I think namespaces are a good idea - in fact, I think
they were the first sign that the people running XML had no clue what
they were doing. I support them because I have to, both to make my
tools usable by others and because I have to deal with namespaced
information. I create it myself sometimes, a habit I got into when
using other people's tools.
2) Communicating expectations is harder than communicating data. Good
documentation and schemas can provide more information, but there's a
lot of experience behind "loosely coupled" vs. "tightly bound",
especially where participants are widely distributed.
3) Bad ideas that start in one place frequently wander elsewhere. W3C
XML Schema is probably the classic example of this. It's widely
despised, even at conferences - like last summer's Applied XML show -
where everyone claims to need that kind of tool. Nonetheless, it
continues to make life difficult for people from Word users to data
binding implementers to XSLT developers.
4) Interop issues grow as more parts need to be more closely compatible.
XML ingeniously threw away the SGML declaration with all its options,
and everything seemed to be good.... until we had new checklists of
conditions that had to be met for interop to work right. I listed some
of the early ones long ago[1], but I can't imagine giving a similar
presentation today. It would deserve at least a week-long seminar, and
I struggled to deliver that version in a day.
I'm happy to see ASN.1 working to make itself more accessible to
developers with different expectations, and I'm still happy to see ASN.1
at work for people who actually want schema-first tightly-coupled
development. I'm not happy to see ASN.1-flavored proposals for
revamping XML APIs because they don't fit ASN.1 expectations. Building
bridges between the two worlds is good, but there's definitely a limit.
XML has suffered enough here from types that you might want to pack up
that circus wagon and find another freak show where it'll be more
welcome. Please don't tell that bogus story about types being a
harmless option if you want me to take you seriously.
[1] - http://simonstl.com/articles/acminterop/interop.html
|
