[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
> 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.?
Give me a break!... It's a two year old document and was
written before X.694 was finalized. However, given X.694, ASN.1
compilers should have no trouble dealing with attributes. I'm assuming
that the folk building SAX interfaces for ASN.1 defined encodings will
"do the right thing" given that they now can. Unfortunately, I don't
know enough about either Objective Systems' or OSS Nokalva's
implementations to be able to say if they are -- yet. However, I'm
sure that market pressure or competing open source projects are likely
to force them to eventually do the right thing, whatever that might
be.
So, this is *not* a good thing to use to prove incompatibility
between XML and ASN.1. It is a historical document that doesn't
reflect today's reality. It is just useful in showing conceptually how
things can be done.
>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.
What is the proper forum in which to hash out the details of
such a type-rich interface for a "SAX 3"? Is it this group (xml-dev)?
Or somewhere else? Given that we can see that there are already two
commercial vendors working on SAX interfaces for the ASN.1 defined
types, and given that a such an interface will be needed/required by
*any* SAX interface to binary encodings, it probably makes sense for
us to define the interface we want as soon as possible so that we
don't end up stuck with the inevitable confusion that comes from
competing solutions.
bob wyman
|
