Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX for Binary Encodings (preserving investment) (ASN.1 an
 Responses to some of these points are in the original text below.. Regards, Ed Day Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-9841 Fax: +1 (484) 875-9830 Toll-free: (877) 307-6855 (USA only) mailto:eday@o... http://www.obj-sys.com ----- Original Message ----- From: "Bob Foster" <bob@o...> To: <bob@w...> Cc: <xml-dev@l...> Sent: Friday, November 07, 2003 3:10 PM Subject: Re: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX) > Bob Wyman wrote: > >... > > Fortunately, it appears that Objective Systems already provides a > > SAX-like interface for ASN.1 defined binary encodings and OSS Nokalva > > is working on a SAX interface for ASN.1 defined encodings. There is a > > paper that talks about the Objective Systems implementation at: > > http://www.obj-sys.com/docs/ASN1CEventHandlersWhitePaper.pdf > > This is a good thing to point to if you want to convince people that > ASN.1 can't handle "real XML". Where are the attributes, processing > instructions, etc.? Binary encodings don't have attributes, processing instructions, etc.. So how are we going to fire non-existent events? This does not make it any less SAX compliant. > > However, assuming all of SAX *could* be implemented... > > > Reading the paper, it becomes clear why Objective Systems' > > implementation is "SAX-like" rather than being simply "SAX." The > > issues that caused them to diverge from plain-vanilla SAX are ones > > that will need to be dealt with by any project which attempts to build > > SAX support for binary encodings -- whether they are the ASN.1 defined > > encodings or some new-fangled "binary XML" which might get invented > > (but hopefully not patented...) > > SAX assumes that the data it is reading is all of "character" > > type. SAX has no access to a schema file and thus has no idea of the > > real type of the characters it reads. However, a binary encoding will > > typically pass data in a form more appropriate for its type. Thus, an > > integer will be passed as something like a 32-bit value, not a string > > of characters. So, to build a "pure SAX" interface to a binary > > encoding, you would have to convert all the binary values to > > characters before passing them to the SAX event handlers. Of course, > > the first thing a lot of event handlers will do is convert the strings > > back into binary types like integers. The result is, of course, often > > wasteful silliness. It causes performance problems, memory > > fragmentation due to all the string allocations, etc. > > So, while SAX interfaces to binary encodings allow us to do > > things like use XSLT processors on binary data, they also raise some > > issues about the SAX interface itself. Knowing that people are already > > implementing SAX interfaces to binary data, it probably makes sense to > > carefully consider at this point how to handle this problem so that > > standardized solutions can be implemented. That would be much better > > than each developer or vendor coming up with their own interpretation > > of what SAX for binary encodings looks like. > > There are a number of possible solutions: > > 1. Insist that all binary types be converted to strings. > > Well, yes. First implement SAX 2 with no exceptions. The fact of the matter is the Java version already does implement the characters method as defined. The reason is because conversions to and from strings in Java are easy and have relatively low overhead. There are memory issues with doing this in C or C++, but they are not that difficult to overcome. We will add it to the list to be done for the next release. > > > 2. Define an "extended SAX" that passes data with descriptors > > that show the type of data. Thus, a program would be told the type of > > the data being passed and could call a ToString or ToInteger function > > as needed. > > Yes, too. > > > 3. Provide a "mode switch" which could be called to modify the > > behaviour of SAX. If "StringsOnly" was set to true, then only strings > > would be generated, if "allowTypes" was set, then types would be > > passed by descriptor. > > 4. Other options? > > What makes the most sense here? > > If the subject is interoperatility with XML applications, unquestionably > the priority must be to implement SAX 2 as it is. > A code generator application would just use a compiler option. If full compliance was required, the generator would add the extra logic to convert to strings and invoke the characters method. > The extension in 2 above could serve as a useful prototype for a "SAX 3" > that can return non-string values. This API would be helpful both to > ASN.1-encoding users who wish to obtain optimal performance and > XML-encoding users who want to use schema-driven conversion to internal > datatypes. > > Bob Foster > > > > > bob wyman > > > > > > > > ----------------------------------------------------------------- > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > > initiative of OASIS <http://www.oasis-open.org> > > > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > > > To subscribe or unsubscribe from this list use the subscription > > manager: <http://lists.xml.org/ob/adm.pl> > > > > > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> > 
|
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
|
|||||||||
