[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Binary XML

• From: Curt Arnold <CurtA@t...>
• To: Michael Brennan <Michael_Brennan@A...>, xml-dev@l...
• Date: Tue, 26 Sep 2000 21:32:13 -0500

It definitely can be addressed at the transport layer in some cases
(http's 1.1 gzip compression or NTFS compressed files) where the
application never sees the raw binary stream, but the transport or file
system transparently provides the decompressed or decrypted stream.

It could also be done as a pseudo-encoding.  However, it is really
orthogonal to both, you could use one compression mechanism with
multiple types of transports and multiple types of encodings.

You could also create a custom URLStreamHandlerFactory or change the
java.protocol.handler.pkgs property to get URLStreamHandler's decorated
with an compression/encryption checks.  However, that is a pretty global
thing which would make it difficult to process stream with different
(application known) public keys and would force some overhead on parts
of the app that didn't care about encryption or compression at all.

At the requirement phase, the focus shouldn't be on the details of
implementation (though some idea of approaches can provide estimates of
the effort required), but whether the requirement is desirable and risk
it poses to development.   I think it is desirable and poses little
risk.  Maybe there is a magic bullet, but everything I've thought of
that works without some cooperation from the parser has been
unsatisfactory.  Since the parser is open-source so the necessary hooks
can be added relatively easy, if needed.

• References:
  • RE: Binary XML
    • From: Michael Brennan <Michael_Brennan@A...>

• Prev by Date: RE: Binary XML
• Next by Date: bug report: msxml3, loadXML()
• Previous by thread: RE: Binary XML
• Next by thread: RE: Binary XML
• Index(es):
  • Date
  • Thread