OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Binary XML

[ Lists Home | Date Index | Thread Index ]
  • From: Curt Arnold <CurtA@techie.com>
  • To: Michael Brennan <Michael_Brennan@Allegis.com>, xml-dev@lists.xml.org
  • 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:



 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS