Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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 
|
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
|
|||||||||
