[
Lists Home |
Date Index |
Thread Index
]
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
|
