SAX2 and XSLT processors

[Oren Ben-Kiki]

David Megginson <david at megginson.com> wrote:

>I wrote:
> > I perfectly agree that the same problem exists for all relevant W3C
> > recommendations. IMVHO, it is wrong to specify such features using
> > http://my.own.company/... URIs. It would be very much in the spirit
> > of SAX to specify them under http://xml.org/... instead.
>
>The trouble is that we've created a centralized registry bottleneck --
>a single person has to approve every new feature and property name to
>avoid name collision.


And that's what we wanted to avoid in the first place... Point taken. But it
seems inevitable for the particular case of W3C standard features.

>Except for a few core SAX2 features and properties (and there may
>already be too many), I think that there are great advantages to
>letting the market decide what to use, and then (slowly) migrating
>feature names into the core if there's great enough demand.


I agree with this as far as "new" features are concerned, since whoever
introduces the new feature presumably also specifies the feature and
property names. Not to mention that being a "new" feature, nobody would be
forced to use it. It makes for a wonderful way for the industry to evolve
SAX and XML, instead of standard organizations. That said...

W3C features are different in two important respects. First, these are
features one _must_ use to comply with "official standards". There's much
less of a "market decision" whether to use them or not. Second, the people
defining the standards did not bother to specify matching SAX2 features and
properties. And yet, we need a universal name for each such feature. The
solution might be to lobby the W3C to provide these names. Can anyone from
the W3C comment on the likelihood of this?

Assuming that it won't happen, "we" will have no choice but to appoint
someone to act as a proxy to the W3C for the purpose of defining these
names - with an emphasis on "one". This "one" should be acceptable to most
developers, otherwise he'll be ignored. For better or worse, our only
candidate at the moment is whoever controls "xml.org". Does anyone have an
alternative? BTW, I checked and there's an registered "xsl.org" URI, maybe
they'd like to do this instead?

If we don't do this, then what should a SAX2 parser implementer wishing to
provide a W3C feature do, exactly? Invent his own name and properties for
it? That would mean that switching SAX2 parser implementations would become
much harder then switching SAX parser implementations. "You are in a maze of
standard W3C SAX2 features, all different" :-) That wasn't the idea.

I appreciate the goal of keeping the SAX2 "core" small, though I'm still not
clear what distinguishes features in the "core" - is it the fact they are
specified using the "xml.org" URI? A parser may still choose not to
implement them, for example. If the idea is that "if you implement this
_standard_ feature, this is the way you must do it so others will be able to
use it", then W3C features do belong in this set. If this set is large
that's because XML complex, which isn't something SAX can solve. Let us just
be glad we aren't dealing with SGML :-)

At any rate, if you still feel uncomfortable with the W3C features, how
about packaging them in a separate group - a "W3C" feature set, say, which
would be independent of the "core" feature set, but would still be under the
control of xml.org? That would mesh well with the naming scheme I proposed -
that is, "core" features would be under "xml.org/features", but "W3C"
features would be under "xml.org/features/w3.org".

I'd be interested with what XSLT processor implementers have to say on this.
Would you consider packaging the processor as a SAX2 parser? If so, what
feature names would you use or would like to use?

Share & Enjoy,

    Oren Ben-Kiki


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)