Is there anyone working on a binary version of XML?

[Didier PH Martin]

Hi,

We have also to consider that the transport mechanism can provide
compression. HTTP has already this unused feature. I made some tests with
HTTP 1.1 and compression transport and got for any text transport some
improvements. Because the compression is taken care in the transport layer,
the XML parser receives a document as usual.

When I probed the mechanism further here is what's happening in IE
(Currently we are working on a paper for new architecture for Mozilla
Netlib).

IN IE 5.x
the server sends the data in HTTP 1.1 compressed mode.
the client receives the data in compressed mode, then for each 8K chunks
calls a MIME filter that does the decompression.
After the decompression is done by the MIME filter, the transaction handler
give the chunks to the document handler and therefore to the parser.

In Mozilla we do not have this intermediary step. The transaction handler
deals only with a protocol handler and a MIME filter is missing. To be more
versatile and be able to process the stream adequately we have to add the
notion of filters.

So, as already mentioned in Simon's XML architecture we can say that
browsers implements some parts of the layers like:

a) transaction processing
b) MIME filtering (compression, decryption, etc...)
c) Document handling routing

So in a browser's architecture we have:

Transaction handler ----> Protocol handler -----> MIME filter------>
Document manager ------> document handler (here you find the XML parser)

In IE, these elements are already independant of the browser and are
encapsulated in a module called UrlMon. basically, you provide a display
name like "http://www.netfolder.com/ and urlmon act as a transaction
handler, calls the MIME filters and give you the data.

In Mozilla new Gecko architecture this is also a separate XPCOM module named
Netlib. You also provide a display name, the module act as a transaction
handler, calls the right protocol hanlder and give you the data (encrypted,
uncompressend, etc). There is work in progress to add the notion of MIME
filters.

Both module share a similar kind of interface based on COM. This simply
means that an object can have multiple interface and that a Query interface
mechanism is available to obtain the right one. So Mozilla XPCOM and
Microsoft COM implementations are very similar. Both kind of objects have
binary signatures in the form of a C++ pure virtual interface. Both
interfaces have mendatory members like AddRef, Release and QueryInterface.
The difference being the way you instanciate objects and how they are
registered. But, in both cases, the transaction manager and its helper
modules: protocol handlers and MIME filters are accessible to other
applications than browsers.


There is also an other thread of evolution named HTTP NG.

As you know, HTTP is like an remote object with Get, Put, Post, Delete
methods. WebDav (already implemented in IE 5.x WebFolders) recently added
PROGET, PROPUT, etc.... HTTP NG intents is to be able to create any kind of
objects and the actual HTTP 1.1 (WebDav) being one type of object: a
Document object. So, with HTTP NG, you'll be able to create your own object.

This means that the evolution of HTTP on one side and XML on the other side
is creating a concurrent to OMG. Here's why:

OMG as already mentioned in this list is a middleware with:

a) an interface language that could be mapped to different languages for
concrete implementation
b) a marshalling format for object communication.

So, here is what's happening in the Web world:

a) the interface definition language is still absent and it could be OMG
IDL. But today, no choices has been made on this. We'll need some more work
on the HTTP NG front before this happens. But when this will happens, the
web will be a web of diverse distributed objects and not solely distributed
documents.
b) the marshalling format is becoming more and more XML.

However the drawback for XML is that it is wasting a lot of transport
bandwidth compared to other more efficient formats. To palliate that, the
transport layer tries to use compression to reduce the packets payloads.
HTTP 1.1 already provides this, but this is not used very often (if not at
all). As you know, things are moving slowly. In the next 3 to 4 years, most
browsers in the field will support HTTP 1.1 and compression (about 65% does
today). The worst case is server side where a lot of improvised servers are
not well configured to support adaptative compression negociation even if
they can. This is mainly a knowledge barrier and not a technical issue. but
in some years form now, compressed transport will be the de facto way.

This was my Sunday morning .2 cents.

Regards
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)