[
Lists Home |
Date Index |
Thread Index
]
On November 8, 2003 12:38 pm, Simon St.Laurent wrote:
> I can stomach binary interchange. I just don't want the people pushing
> binary XML to make changes to XML processing while doing it. That's
> what Bob seems to be up to, and that's worth drawing a line.
>
> I'd be thrilled to see ASN.1 readers which produce SAX2 events and ASN.1
> writers which consume SAX2 events. I'm not happy to hear notions of
> PSVI-like typing polluting the SAX2 space. If you want typing, find
> another API - and accept the costs of doing that. If the ASN.1
> community wants to reach out to the XML community, it needs to create
> ASN.1 tools which talk to XML tools without imposing ASN.1's own and
> different perspective on how data should be presented.
Such a solution is possible, but it requires use of polymorphism, instead of
simple character arrays.
I believe the proposal to extend SAX for use with ASN.1 is based on
performance. The thought is that converting from typed data to text strings
and back to typed data is pointlessly inefficient. This inefficiency prompted
the proposal to extend SAX with an API that bypasses the text conversion and
directly passes the typed data to the application.
An alternative solution for this efficiency issue is to optimize out the
conversions using a lazy execution design pattern. Instead of passing an
actual text string to the SAX handler, you pass an object that wraps the
concrete data type, and only performs the conversion to text if the
application uses the object through the String API. The data type decoder
(ie: the code that converts from text strings to data types) first checks its
input to see if it is one of these wrapper objects. If so, the decoder just
extracts the contained data type. Otherwise, the decoder uses the input as a
text string and decodes it as before.
This solution optimizes out the string conversion inefficiency without
changing the SAX API. Code that works on the input stream as simple text
continues to function as is. The wrapper objects convert the typed data to
text on demand and transparent to the SAX client code.
Implementing this kind of solution without change to the SAX API requires that
the programming language completely support polymorphism. Unfortunately,
popular languages, like Java, don't have this support. In Java, you can't
create a subclass of a character array, and the SAX API is defined in terms
of character arrays. Could the two sides compromise on a modified SAX API
that was defined in terms of a polymorphic string type?
If you'ld like to better understand this solution, the Waterken Doc library
implements it. See:
http://www.waterken.com/dev/Doc/
The SAX-like interface is:
http://www.waterken.com/javadoc/Doc/com/waterken/doc/Visitor.html
The polymorphic String type is:
http://www.waterken.com/javadoc/ADT/com/waterken/adt/Source.html
Some of the wrapper types are:
http://www.waterken.com/javadoc/ADT/com/waterken/adt/string/String.html
http://www.waterken.com/javadoc/Enc/com/waterken/enc/base64/Decoded.html
http://www.waterken.com/javadoc/Enc/com/waterken/enc/base10/Decoded.html
I haven't kept up with the many messages in this thread. Apologies if this
kind of solution has already been suggested.
Tyler
--
The union of REST and capability-based security.
http://www.waterken.com/dev/Web/
|
