Re: SAX2 and XSLT processors

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

David Megginson <david@xxxxxxxxxxxxx> wrote:

>Oren Ben-Kiki writes:
>
> > One interesting way for doing it would be to build upon the SAX2
> > extension mechanism, providing a standard SAX2 feature called
> > http://xml.org/sax/features/xslt-transformation and a write only
> > property it uses, called
> > http://xml.org/sax/properties/xslt-stylesheet which takes an
> > InputSource value.
>
>I think that it's a great approach, but the feature and property
>probably don't belong in the core, for two reasons:


That depends on what you mean by "belonging in the core". Certainly a SAX
processor isn't required to implement the feature.

>1. XSL is not yet a recommendation; and

It will be, soon, or so we hope; let's assume for the sake of discussion its
August and a final draft is out.

>2. there are many other specs, such as RDF, XML Linking, and XML
>   Schemas, that could fairly claim equal treatment.


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. That is, I feel that _all_
features necessary for implementing XML standards (be they from the W3C or
from anywhere else) do "belong in the core".

How about the following solution: Reserve the
http://xml.org/sax/features/w3.org/ and
http://xml.org/sax/properties/w3.org/ base URIs for specifying features and
properties for implementing features and properties for implementing W3C XML
recommendations. These prefixes would be followed by the internal part of
the URI the W3C uses the recommendation - for example, "XSL/Transform/1.0" -
and then followed by a sub-feature of a property name, if necessary.

For XSL, we'd get http://xml.org/sax/features/w3.org/XSL/Transform/1.0 and
http://xml.org/sax/properties/w3.org/XSL/Transform/1.0/stylesheet. Similar
features and properties would be defined for RDF, XLink, XSchema, etc. If in
the future some other organization - "std.makers.org" - contributes relevant
standards, we'll define http://xml.org/sax/features/org.makers.std/..., etc.
This way "standard" features would have "standard" names.

>That said, there is no reason at all that someone couldn't define such
>a feature and property outside of the SAX2 core list and let the
>market decide.


I can't see "someone" other then w3.org or xml.org being able to pull this
off. For example, I'm perfectly willing to contribute the URIs
http://com.publishare/sax/features/xsl-transformation/1.0 and
http://com.publishare/sax/features/xsl-transformation/1.0/stylesheet for
specifying XSL transformations and specifying an InputSource for loading the
stylesheet.

What's the chance that implementers will wrap their XSL processor this way?
Consider that "http://publishare.com"; is a URI controlled by my company, and
therefore refers to a particular product ("PubliShare", not released yet)
which happens to use XSL. We'd certainly enjoy the resulting publicity
within the XML community, but the chances that Microsoft (or IBM, or Sun, or
any other company for that matter) will provide its XSL processor using
these URIs is pretty slim.

If, on the other hand, we (XML developers) accept SAX2 and within it a way
to specify all standard XML recommendations, under a neutral name such as
"xml.org", there's a pretty good chance that implementers will bother
complying.

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list