[
Lists Home |
Date Index |
Thread Index
]
Dear Bob, I am trying to have a technical argument. So please spare me
your lame attempts at name calling by changing subject lines and
implying some ulterior motive.
More below.
> -----Original Message-----
> From: Bob Wyman [mailto:bob@wyman.us]
> Sent: Tuesday, November 18, 2003 12:40 PM
> To: Michael Rys; 'Murali Mani'; 'Michael Kay'
> Cc: xml-dev@lists.xml.org
> 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.
[Michael Rys] I see no technical counter-argument so far...
> 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.
[Michael Rys] Correct. However, but mandating that every side
understands more than 1 format, you are adding complexity to the overall
system that would have to be balanced by a big enough benefit. This in
the end needs to boil down to a benefit/cost ratio that can justify the
additional cost. My point is that there is a large cost to adding a
binary format, and given that most binary formats are done for a
specific purpose (compression, more efficient parsing, not datatype
serialization/infoset transport), many of which conflict with each
other, I do not see adding a standardized format is having such a
benefit/cost ratio.
> 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.
[Michael Rys] The whole point of XML based interop is that you can send
the data on the wire independent from the API. By defining interop on
the API level, you are missing the point of using data instead of code
to achieve information exchange and interoperability. Using an XML API
over relational databases or ASN.1 is fine, but it only gives you the
wrapper part of a mediator architecture that allows you to integrate
information from different sources (which is basically just another way
at looking at the loosely-coupled aspect).
> > 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.
[Michael Rys] That is all fine and well. But you may realize that most
of these layers only add different formats if the benefit/cost bears it
out.
One use case that was quoted at the binary XML workshop was that small
mobile devices needed a binary XML format since they cannot work with
textual XML. If that is the case then these devices would claim interop
with XML without supporting the textual format. This seems like a bad
idea for interop.
[Michael Rys]
> 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...
[Michael Rys] I have no problem with tightly-coupled systems using other
formats. A lower-level in the OSI model can certainly chose to transport
the XML in a different format. The main point about XML is that it is
not only transport encoding of relational data or some message format,
it is not only textual markup: it is both and therefore it can be more.
If you start designing for only one of the two and make them peers to
the XML format, you are making the standard worth less (and in some
people's opinion worthless).
> But this argument for consistency and single standard formats
> is a bit disingenuous coming from an Microsoft employee...
[Michael Rys] Looks like you are back at name calling and
generalizations....
> 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.
[Michael Rys] Hmm, maybe I agree with this from a standard and
interoperability point of view. But nah, can't be, I am a Borg now...
:-)
> > 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.
[Michael Rys] Correct. However, you need to run your benefit/cost
analysis again...
> 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...
[Michael Rys] Not really. Every system component that makes assumptions
about its other system component's internal way of using or producing
data in my opinion is closely-coupled (beyond a simple give me data). If
a company A provides a webservices implementation that provides full
SOAP 1.2 compliance on the server and client and in addition provides a
special binary format for components that know about each other (they
need additional protocol), then in order to build loosely coupled
system, it is beneficial to have only one interop format. If other
components want to use the special format and want to be more closely
tied to a specific component, that's fine too. But claiming that you
help interop by having two or n peer standards is not helping interop.
>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.
[Michael Rys] I think that every fiefdom can use whatever currency and
language they want to use. But if you want to simplify interop, you
should standardize one currency and one language, one measurement system
etc and not have two. There is nothing in my mail that claims that
others cannot use a binary format. But once you want to enable real
interop, I think having only one standard format is much preferable to
n>1.
> 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...
[Michael Rys] Huh? I would really like to see how you can infer this
from my arguments. I am arguing in favor of keeping the interop world
simple and you construe from that that I want total world domination for
Microsoft? Give me a break...
> 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.
[Michael Rys] I am not refuting these points. I actually agree with them
at a general principle level. However, this is not speaking to the point
that when you start to have n peer standards, that you hamper interop
and I don't think I said anywhere that you should not use standards. All
I said was that in tightly-coupled systems the benefit/cost ratio may
tilt more towards a binary format that does not need to be standardized
for interop reasons.
> 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.)
[Michael Rys] Interesting. My wife worked at ASCOM more than 10 years
ago with ASN.1 and I worked with ASN.1 during my research in information
integration (build an ASN.1 to OEM wrapper on MEDLIB). ASN.1 would have
been a useful interop format for data exchange if it would have been
simpler and only text-based. By providing the different binary
encodings, it hampered its adoption for interoperability because of the
added complexity and costs for tools. Up to the point XML came along and
was doing this right and provided the additional benefit of being usable
for markup and data. I don't think making XML more complex will be a
good idea given my experience with ASN.1 over the last 12 years.
> 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.
[Michael Rys] I don't care if you use ASN.1 on a lower-level as the
physical transport level on an Ethernet to represent XML. I care about
having to provide webservers that need to send and receive both XML and
some binary format in order to stay interoperable.
> bob wyman
>
|
