[
Lists Home |
Date Index |
Thread Index
]
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@wyman.us]
> Sent: Tuesday, November 18, 2003 12:40 PM
> To: Michael Rys; 'Murali Mani'; 'Michael Kay'
> Cc: xml-dev@lists.xml.org
> Subject: [xml-dev] 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>
|
