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


Help: OASIS Mailing Lists Help | MarkMail Help



   Polymorphic strings (Was: [xml-dev] SAX for Binary Encodings (SAD-SAX))

[ 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:


The SAX-like interface is:


The polymorphic String type is:


Some of the wrapper types are:


I haven't kept up with the many messages in this thread. Apologies if this 
kind of solution has already been suggested.


The union of REST and capability-based security.


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

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