Lists Home |
Date Index |
On Fri, 7 Nov 2003 20:14:22 -0500
"Bob Wyman" <email@example.com> 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.
Whatever scathing things I have to say about ASN.1 (I have *lots*, and I
haven't exhausted my repertoire yet), it *does* have a type *system*. A
rational one. It is, in my opinion, somewhat limited, and over-tightly
focused on solving a particular set of "business" type problems, but at
least it isn't a total botch.
RNG already demonstrates how a type library can be integrated into a
schema language that otherwise restricts itself to the definition of
"complex types". It is trivially easy to do the same thing with W3C XML
Schema (just drop part II, and replace it with a mechanism to declare a
type library containing primitives). It's true that that doesn't exist,
at present, for WXS, but given that the primitives system is chaotic to
start with, and can only be modified by fiat of the overseeing WG
authority, the facility to toss the botch and use something rational has
to look attractive to even the fiercest of WXS partisans ... soon or
If you want something SAX-like, or that can live on top of SAX, but that
generates types events in place of the SAX attributes and characters
events, then *do not* hobble it in advance by defining the events in
terms of WXS. Use something systematic. ASN.1 *may* have a lot to
offer the data-heads in the XML world, if they could just bring
*rationality* to the discussion of simple types, where currently is
chaos, disorder, and nine variations on gHorribleKludge.
My opinion only, of course, and given the skepticism bordering on
hostility that I've previously expressed, perhaps not worth much. But
note, please, that the XQuery folks are going to be running this
gauntlet, probably soon. They've tied themselves inextricably to the
WXS type s- s- s- ... collection. It's going to be an issue, in last
call and probably after ('cause it prolly won't disappear after last
call, and folks who would be willing to accept a built in type *system*
will nonetheless object to a language that relies upon a type botch).
SAD, isn't it?