Re: [xml-dev] SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)

["Ed Day" <eday@obj-sys.com>]

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@obj-sys.com
http://www.obj-sys.com


----- Original Message -----
From: "Bob Foster" <bob@objfac.com>
To: <bob@wyman.us>
Cc: <xml-dev@lists.xml.org>
Sent: Friday, November 07, 2003 3:10 PM
Subject: Re: [xml-dev] 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>
>