[
Lists Home |
Date Index |
Thread Index
]
Joshua Allen wrote:
> Are you arguing that the world before XML was "just fine"?
Of course not! Before XML, on the Internet, every time someone
created a new protocol or new product, they also created a new
on-the-wire encoding format, often a new schema language (or a
reinterpretation of something like ABNF), and often a new file format.
It was insane! In fact, it is just this insanity and confusion that
motivated folk working on OSI, mail systems (X.400) and directory
services (X.500)back in the 80's to define ASN.1. ASN.1 did for us
then, in that restricted realm, exactly what XML is now, finally,
doing for the Internet and the rest of the world.
As far as I can see, there are virtually no differences
between the XML approach and the ASN.1 approach other than the fact
that one is human readable and the other requires transformation
before being human readable. Other than being directly readable by
humans, virtually every other "benefit" attributed to XML is something
that can be said equally of ASN.1. For a long time, XML didn't have
schemas, but even that is fixed now. (Now there are many XML schema
languages -- including ASN.1).
The truth of the matter is that when this SGML vs ASN.1
conflict began about 20 years ago, the two sides should have gotten
together and said: "Let's define SGML encoding rules for ASN.1 to go
along with BER." That would have given us all 20 years of consistent,
standard, inter-operable data exchange. It is not too late to finally
make the compromise today. Let the binary folk have binary and let the
text folk have XML -- as long as the two encodings are completely
interchangeable and based on standards.
> by arguing that XML-text has no special interop characteristics
> that distinguish it beyond others. If you feel that way, and
> if you feel that ASN.1 is "just fine" for loosely-coupled
> interop, then what are you doing wasting your time on XML-DEV?
XML is massively better than many of the other text-based
interchange formats that have been proposed. I much prefer it to say:
RFC822 name value pairs or the X12 EDI stuff. If you're doing
human-readable text encoding, XML is great. It's easy to program for,
easy to teach people, etc. It's even a great "value notation" for use
in ASN.1 schemas! But, it sucks for many applications that require
binary data. I have never argued that XML isn't valuable or that ASN.1
defined encodings are better in all cases. What I will argue is that
sometimes XML is the best choice and other times one of the ASN.1
binary encodings is the best choice.
We need *both* XML and the ASN.1 defined encodings. If we have
both, then we can eliminate virtually all arguments for defining *any*
new encodings. At that point, we'd be where we should be. At that
point EVERYONE would be using well understood, standardized encodings
for interchange -- not just the folk who can live with XML's slow to
parse, fat but wonderfully easy to read and process encodings. (Note:
Before you say XML is fast enough or compact enough for *you*,
remember that there are folk with tighter requirements than yours...)
I want ASN.1 defined encodings to be accepted for all the same
reasons that XML people seem to fight this idea. (i.e. to increase
ease-of-use and inter-operability) And, I want ASN.1 defined encodings
to be accepted since I think that is the best thing for the movement
towards integration and interoperability that XML has been key to
enabling. I view my arguments as being "good for XML," not as an
argument against XML. I hope that is clear.
ASN.1 encodings are not and never will be "replacements" for
XML. We will always have use for XML just as we will always have
people that need binary encodings. But, rather than fighting, these
two groups should be working together. Let's kill this decades old
perma-thread by cooperating.
bob wyman
|
