RE: Binary XML

[Stuart Naylor <indtec@eircom.net>]

I thought the only way you could get binary through port 80 is in a mime
wrapper. This gives it a layer of encapsulation in a effort to render it
safe.

Port 80 is text only even if you can hide binary in wrapper it still is
a text tranfer but how would this work with binary xml.
Would this also be included in a wrapper so we have a unicode protocol
represented as binary then wrapped in a mime type to be unwrapped so
that processing can occur ?


-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@allegis.com] 
Sent: Thursday, July 26, 2001 9:36 PM
To: 'Stuart Naylor'; xml-dev@lists.xml.org
Subject: RE: Binary XML

The issues with COM and CORBA through firewalls has nothing to do with
the
fact that they are binary protocols. It has to do with the way these
protocols use ports, and the fact that many firewall configurations only
permit traffic through particular ports (and sometimes filter traffic
that
does not conform to a specific protocol, such as HTTP). In contrast,
HTTP is
pretty ubiquitous and sticks to its designated port. Contrary to some
myths,
HTTP can be used to carry any type of content -- binary or otherwise.
HTTP
is really not particularly well suited for some of the purposes for
which it
is being used, but it's there and it's easy to piggy-back other
protocols on
top of it.

With that said, much of the talk of "binary XML" is misguided, IMO.
There
is, unfortunately, widespread ignorance of what prevailing, established
protocols already provide for solving many of the problems that "binary
XML"
is supposed to address. Some of the suggested use cases include:

1) A binary protocol can be more efficient to parse into in-memory data
objects. I think this is bogus. When sending over a WAN, network latency
will make this parsing overhead insignificant. On a high-performance
LAN, a
situation that needs that extra efficiency may be better served by using
CORBA, COM, or a similar RPC mechanism. XML is not a panacea, and not
every
problem needs an XML-based solution. The valid use cases for this are a
fraction of what some suggest, IMO.

2) Faster throughput over a WAN. There are already established ways of
dealing with this. The HTTP spec explicitly supports compression using
proven protocols (gzip, deflate). These same compression protocols could
be
used over other transport protocols, as well. Inventing a "binary XML"
format purely for this reason is simply pointlessly reinventing the
wheel.

3) Providing optimized random access to fragments from large documents.
This
one is interesting, but is probably better served in the more general
cases
by XML databases, which is an evolving area.


> -----Original Message-----
> From: Stuart Naylor [mailto:indtec@eircom.net]
> Sent: Thursday, July 26, 2001 11:23 AM
> To: xml-dev@lists.xml.org
> Subject: Binary XML
> 
> 
> Can someone explain to me the idea behind binary XML.
> 
> My initial interest in XML was due to the pitfalls of using binary
> distributed objects such as COM / CORBA. The protocols worked fine but
> had major problems when presented with a firewall and 
> security settings.
> 
> I am just interested in how binary XML will circum-navigate all the
> security scares that the doom & gloom consultants attach to binary
> methods.