[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
> To clarify my previous suggestions, as open source projects:
>
> 1. Implement the full SAX 2 API over a meaningful subset of ASN.1.
>
> Maybe it's just me, but you can say 'till you're blue in the face that
> the full SAX 2 API can be supported over ASN.1. When I see the code,
> I'll believe it.
Well, the reference implementation would be to take a
PER-or-whatever-to-XER converter, and then pipe the output into a SAX 2
parser... And you can do the reverse; write code that takes a SAX event
source and outputs XML, and pipe that into an XER-to-PER converter.
Since XER<->[P|B]ER converters are already compiling and running, and
SAX parsers have been seen in the wild too, then does that count as
'running code'? :-)
Of course, there are significant optimisations that can be made by
removing the stage where you have it in XML, and just go straight from
ASN.1 abstract value to SAX stream or vice versa.
> 2. *Then* prototype an extended SAX API compatible with the above that
> has just enough change to allow it to serve up internal datatypes on
> demand. The more type system agnostic (while still meeting the desired
> performance goals) this can be, the better.
One way of making it type system agnostic is to define the types in
terms of the type system of the programming language you're using it
from. So if you're using the C rendition of the typed-SAX API, then
you'd get informed of ints, longs, and so on. If using a Lisp rendition,
it be 'fixnum' or 'bignum', which have somewhat different semantics to
the C equivelants, etc.
>
> Bob Foster
>
ABS
|
