[
Lists Home |
Date Index |
Thread Index
]
OK, so you are just saying that XML people should care more about ASN.1
and should work better with ASN.1? This is not such a bad opinion, but
one for which I don't have a ton of sympathy. This is just because from
my perspective and the perspective of most customers I've worked with,
ASN.1 doesn't have a ton of relevance to the apps they are building with
XML, and there is no real demand to make them work together. The vast
majority of them want XML and CSV to work better together, and some of
them want XML and IIOP/RMI/DCOM to work better together, and many even
want to see XML and EDIFACT work better together. But I can honestly
say I have not seen a single legitimate customer scenario where they
wanted ASN.1 and XML to work better together. Your experience may
differ...
I would also say I think that we need to be very cautious about assuming
that the world needs both a binary and text encoding -- people gripe
about parse speed of XML as if it will be faster when it's binary, and I
think this is incorrect from two perspectives -- first is that we have
shown XML-oriented protocols to be faster than binary in many cases, and
second because there is still tons of room for improvement in text
parsing speeds (the fact that gen 1 of XML parsers is slow simply proves
that they are gen 1 parsers, not that text is inherently slower than
binary).
> -----Original Message-----
> From: Bob Wyman [mailto:bob@wyman.us]
> Sent: Tuesday, November 18, 2003 2:40 PM
> To: Joshua Allen; 'Murali Mani'; 'Michael Kay'
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Microsoft FUD on binary XML...
>
> 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
|
