[
Lists Home |
Date Index |
Thread Index
]
Amelia A Lewis wrote:
>
> On Fri, 7 Nov 2003 20:14:22 -0500
> "Bob Wyman" <bob@wyman.us> 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
|
