[
Lists Home |
Date Index |
Thread Index
]
On Thu, 2002-05-09 at 13:20, Matthew Gertner wrote:
> I'm surprised that you consider XML to be "an ugly foundation for building
> information interchange systems". Going back to Bosak's original vision of
> "SGML on the Web", the key to XML's success is that a lot of information
> interchange problems combine the attributes of document and data. This is
> true of everything from flight availability data to business documents like
> invoices.
I have no qualms about saying that textual representations with
fully-expanded end tags are an inefficient means of shipping large
quantities of integers and dates around, not to mention the thrills of
binary data. (base64? hexBinary? wow. Incredible, even.)
XML is a wonderful foundation for building certain kinds of information
interchange systems, and a key tool for making it clear that information
interchange is in fact possible. XML is not an ideal tool for
exchanging all kinds of information, however. The metadata costs of
working with a text format spiral rapidly as more complex types than
element structures and attribute annotations are applied.
> All of these things benefit from text-based markup: you can view and
> understand the raw data, transform itwith a stylesheet, format it for
> viewing using HTML (very common use case), manipulate with Perl, awk, grep
> and other text processing languages, etc. At the same time, these things
> benefit from semantic information as well. I don't see the contradiction.
>
> The types native to W3C XML Schema are overblown, I agree.
Good.
> But the types in
> XML are a little goofy as well, to say the least.
Sure. I think of them as pretty much constraints for connecting
document parts, not really types per se. The types I find useful are
element and attribute names.
> When was the last time you
> used NMTOKENS?
A few years ago, probably for DDML. I tend to stick to CDATA and the
very occasional ID/IDREF/IDREFS.
> My point is that the notion of letting the user *choose*
> between well-formed and valid is one of the key aspects that has made XML so
> successful, and it should be retained in both directions (i.e. for those of
> us who partake in schema and those who don't).
So do you want a PSVI or not? And do you prefer the PSVI to plain XML?
> At the same time, DTDs are
> definitely inappropriate for B2B e-commerce and other XML "killer apps", and
> creating an alternative that uses XML syntax and has a more logical set of
> basic datatypes (like the one I proposed) makes a ton of sense.
I'm having a very hard time these days believing that B2B and e-commerce
are "killer apps" for XML. I'm happy to acknowledge that XML was an
enabling tool that let people realize that common foundations are good,
but I doubt that XML per se actually makes those apps great. A
text-based format lowered the entry cost, but has other costs if data is
your main priority.
> The exciting thing about XML to me and a lot of people is that we are
> abstracting interfaces away from fragile APIs to the level of business
> document formats that everyone company understands (orders, invoices, ASNs,
> etc.). These look beautiful when marked up using text, and they are also
> strongly typed. You'd have to get a lot more concrete to convince me that
> text-based markup+schema is not the most elegant way to represent them!
What is this constant call for concrete? Stalinist architecture at its
finest? Sadly, architectural issues don't always benefit from angle
brackets, though they may certainly affect them.
Text editors are one cheap way of looking at your information. That
doesn't mean XML is naturally the right answer. How many times have I
had to put up with people who insist on keeping humans away from
markup? All I'm doing is giving those folks what they want, plus an
efficiency bonus.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
