Subject: Re: SAX2 and XSLT processors From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Thu, 20 May 1999 15:30:43 +0200 |
David Megginson <david@xxxxxxxxxxxxx> 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 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: SAX2 and XSLT processors, Oren Ben-Kiki | Thread | Re: SAX2 and XSLT processors, Oren Ben-Kiki |
how to use xslt extension functions, Smith BC (Brian) at | Date | xsl examples, David Carlisle |
Month |