Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Microsoft FUD on binary XML...
 Are you arguing that the world before XML was "just fine"? That is certainly what you seem to be arguing, 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? Trolling, perhaps? You cannot deny that XML has succeeded in large part because it is text and because it is perceived as "the obvious choice" to many people. The world was a lot different before XML came around, when people had to choose between a dizzying array of binary and text syntaxes (including ASN.1). Anyone who tries to complicate and fragment this serendipitous development is, IMO, insane. > -----Original Message----- > From: Bob Wyman [mailto:bob@w...] > Sent: Tuesday, November 18, 2003 12:40 PM > To: Michael Rys; 'Murali Mani'; 'Michael Kay' > Cc: xml-dev@l... > Subject: Microsoft FUD on binary XML... > > Michael Rys wrote: > > Binary XML in my opinion flies in the face of loosely-coupled > > interoperability. > Pure FUD. Give me a break. As an ex-Microsoft employee and as > someone who has a great deal of respect for much (but not all) of > Microsoft's technical contributions, I would have expected you to come > up with something better than this argument. > There is nothing about binary encodings that interferes with > loose coupling of systems or interoperability as long as those > encodings are clearly defined and consistently implemented by both > sides of a connection. The exact same conditions apply to the use of > XML. XML is only useful in a network where both ends of a link > understand what XML is and how to work with it. The situation is no > different for binary stuff. > Also, given encoding-independent implementations such as those > that I have been arguing for, the details of processing on-the-wire > encodings are hidden from programs in such as way that an XML stream > and a stream of ASN.1 defined encodings appears to the program to be > identical. Given a SAX interface that implements the XMLReader > interface over ASN.1 defined encodings (like the SAXASN1 that I'm > working on...), a program simply can't tell whether it is dealing with > XML or BER. This means that the encodings are completely > interchangeable and there is not loss either to the ability to define > loosely coupled systems or to interoperability. > > > By adding a "standard" binary XML format (be it based on ASN > > PER/BER or some other scheme) the interoperability gets > > bifurcated and the advantage of a single, auditable, > > interoperable format to be used in loosely-coupled environments > > disappears. > This all depends on what level in the protocol stack you are > looking at. Clearly, you've chosen a specific view of the stack that > serves your particular interests. But, that doesn't mean that others > must accept your view. > If you go further down the stack, you'll see that data can > either be encoded for Ethernet transfer, for transfer over hard wires, > or even for transmission via carrier pigeons (read the RFC). The fact > that low levels of the stack have multiple, interoperable > implementations has done nothing to restrict interoperability, > auditing, etc. In fact, the alternative implementations and encodings > at lower levels in such a way that they present consistent, > standardized interfaces to higher levels, has increased dramatically > the opportunities for interoperability, auditing, etc. in our networks > today. > When I call for accepting XML and binary forms as peer, > interchangeable encodings, what I'm really doing is just emphasizing > the OSI "presentation" layer and encouraging people to write code > above it, not in it or below it. If you do your auditing and > interchange from above the presentation layer, there is no problem. > You are simply not concerned about how the actual bytes or octets were > formatted at the layers below you -- just as you should not be > concerned with whether your bytes moved over electrical wires or if > they were moved by carrier pigeons at a lower level in the stack. > If one implements an encoding-independent application, there > *is* a *single* format. That format is the program's view of the data > -- i.e. the program's interface to SAX, to DOM, or to whatever else it > might be using to read the data. This is just as today, the programs > view of the data is the buffer that comes from a socket, or a file, > etc. The question is simply one of where you cut the layers... > But this argument for consistency and single standard formats > is a bit disingenuous coming from an Microsoft employee... If extended > it to its logical conclusions, this argument would say that Microsoft > was wrong to make non-standard extensions to HTML (and thus > effectively creating a new format) or in their twisted, non-standard > use of Kerberos, or in their use of NETBEUI and other non-TCP > protocols, or their non-standard extensions to Java, etc. > > > In closely-coupled systems, you can use something else than XML > > (or a binary format). Since the coupling is closed, you do not > > need to follow a standard (although there are some reasons why > > you still may use XML). > Perhaps in what you call a "closely-coupled" system, one might > not *need* to conform to standards, but a good coder, without a > compelling reason to ignore standards, would still use a standard. > Doing so would, of course, increase auditability by allowing the same > tools that worked with loosely-coupled systems to work with the > closely-coupled ones. > But, what is a "closely-coupled" system? It seems that > Microsoft would consider such things to be any system that has their > components on both ends... But, since Microsoft is a monopoly, this > means that a very large proportion of the systems in use can be > considered "closely-coupled". The end-result of this argument is that > Microsoft should be free to use all the weird formats they want while > all non-monopolists are forced to use clunky, fat, "standardized" > formats for interchange. Thus, Office systems can interchange using > some binary format (.doc) while you would argue that others should > not. Basically, you're just setting up an argument that says that > Microsoft has a privileged position and suggesting that we accept that > as a design principle. On the other hand, I believe that in many > cases, the most common justification for maintaining non-standard or > secret formats in "closely-coupled" systems is simply the desire to > keep them closed -- i.e. to prevent the introduction of innovative new > systems developed by others. This may be an economic principle, and it > may be a great way to maintain a monopoly, but it isn't a good way to > design systems. The rest of us still demand *OUR* right to innovate... > In fact, even when designing "closed" systems, one should > always strive to use the open standards. This is true if only to > ensure that if the closed system is ever opened, then access to it can > be provided with minimal effort. There are even basic management > reasons for using standards in closed systems. For instance, it is > typically easier to find potential employees who understand the common > formats than it is to train people in proprietary formats. Anyone who > uses proprietary formats in their systems is increasing their costs > significantly. Often, the only justification for this cost is simply > the desire to exclude -- not any real technical advantage. > ASN.1 provides standard definitions of binary encodings that > have been proven to provide the advantages which are typically > demanded of proprietary encodings in the space. i.e. PER is compact > and fast to encode/decode. The ASN.1 encodings provide loss-less > transformations of XML data. It would be hard to make a really strong > case for adoption, even in a closed environment, for other > non-standard binary formats except in the most specialized > applications. (The only argument would be lack of tool support -- but > that will change soon.) > Anyway, your argument does not hold water. The introduction of > ASN.1 encodings as loss-less, deterministic encodings for XML data > does not compromise our ability to build loosely coupled systems, to > interoperate, etc. Your FUD is not accepted here. > > bob wyman > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
