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
 Amelia A Lewis wrote: > > On Fri, 7 Nov 2003 20:14:22 -0500 > "Bob Wyman" <bob@w...> wrote: > > > Simon St.Laurent wrote: > > > I think you'll likely find massive opposition to such a > thing, both > > > here and at saxproject.org. > > > > Amelia A. Lewis wrote: > > >Second the motion. > > > > Would this go down easier if rather than proposing a SAX 3, the > > proposal was to develop an extension to the SAX 2 XMLReader > interface > > and then use the standard feature and property facilities to allow > > callers to define which callback should be made when > > characters() would normally be called? This could be done without > > perturbing the core SAX 2 interfaces at all. > > First, note that it is perfectly feasible to define an > interface which amounts to a sax processor (on one side) and > a "typed event generator" (for lack of a better term, on the > other side). > > There's no real point in implementing this as a pure sax > filter, since that restricts you to type-less > implementations. What you presumably want is (*cough*, > *cough*) the Simple API for Datatypes. > > Hook up some SAD processor to a (musical) SAX processor, and > you've got it. Even XML sings the blues. > > It will look different from SAX. SAX lies below the schema > level. It generates element events, character events, > attribute events, namespace events. Of these, the element > and namespace events can pass straight through. Instead of > characters (text nodes) and attributes, a SAD processor > generates some form of typed event. > > Now, let me repeat an earlier warning, because I wonder if > the ASN.1 folks are aware that the XML folks (some of them, > in any event) *know* what a botch W3C XML Schema is. The > ASN.1 mappings all rely on W3C XML Schema, with its ... well, > *peculiar*, to be polite ... type (*cough*, *cough*, *hack*) > sys-, err (*cough*), s-, s- (*hack*, *gasp*), umm, > *collection*. Don't tie the API to W3C XML Schema. Use the > ASN.1 abstract type system. Amy - no, the only thing that relates ASN.1 to W3C XML Schema is X.694. X.694 specifies a translation of *schemas* FROM: W3C XML Schema TO: ASN.1 ASN.1 is a data-definition language completely independent of W3C XML Schema, and has the following property (quoting from W3C XML Schema Part 1): "offers facilities for describing the structure and constraining the contents of XML 1.0 documents, including those which exploit the XML Namespace facility." the above being strictly true when EXTENDED-XER is used as the encoding rules. Therefore, it is not true that "ASN.1 mappings rely on W3C XML Schema". ASN.1 relies on itself and on its own EXTENDED-XER encoding rules to produce XML documents. On the other hand, you can obtain PER encodings or BER encodings from an original WXS schema by first translating the WXS schema to an ASN.1 schema and then applying PER or BER. Because the translation specified in X.694 is "canonical" with regard to all standard ASN.1 encoding rules, the ASN.1 schemas generated by any two implementations of X.694 will interoperate "on the wire". "Canonical" here means that although the ASN.1 type definitions generated by different implementations of X.694 may not always be identical, they are such that the PER, BER, etc. encodings will be the same for every possible abstract value. So the purpose of X.694 is *not* to enable ASN.1 to handle XML, but to enable W3C XML Schema to exploit the facilities of ASN.1. Alessandro 
|
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
|
|||||||||
