Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Polymorphic strings (Was: SAX for Binary Encodings (SAD-SAX))
 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
