xml-dev - Re: SAX Future

[David Brownell <db@Eng.Sun.COM>]

Re the Java parts of that future:

Michael Kay wrote:
> 
> >Yes, but how do we accomplish this?  Do we invent a new package name
> >for SAX 1.0.1 to avoid collision?
> 
> I suspect we have to - unless someone knows a better way. Given that parsers
> include the SAX interface classes in their distribution, we don't really
> want people to have several different definitions of the same interface on
> their classpath.

As has been pointed out, strict binary compatibility for interfaces
ensures that this won't happen.

How to ensure that in the face of multiple distributions gets into
some legal issues.  Since SAX is in the public domain, it's got an
odd set of problems ... anyone can ship whatever they want and call it
SAX, in effect.  (We have no intention to do such a thing.  Sun is
very interested in "doing the right thing" here, working with David
Megginson and others.)

I think that part of the solution is to have conformance testing both
for SAX interfaces and for parsers implementing them.  Two parsers
should agree on what "fatal errors" are, for example, as well as the
data passed from the parser given specific input.  (Modulo the fact
that a block of text can be reported in one block or many, and so on.)


> There are other version control nasties lurking in the "helper" classes. For
> example SUN's distribution includes a modified version of ParserFactory,
> under the original package name and class name. (The modification is to load
> SUN's parser if no other parser was specified).

That is, a configuration error is transparently recovered from.

Anyone asking for a specific parser will always get it.  Anyone wanting
errors has countless ways to generate them ... ;-)

Of note:  This is the first comment we've received on this clearly
documented
change!  The method "Create[s] a new SAX parser using the org.xml.sax.parser
system property", per spec.


>	 However well-intentioned
> SUN's actions, I think this should be banned - and we should design SAX
> 1.0.1 to make it unnecessary.

I'm curious how you'd design an updated SAX to not have the capability of
such a configuration error.  Get rid of the notion of a default system
configuration, pushing the problem up to application developers?  That is
the approach some other systems take.

Re "banning" ... without some conformance testing, what would that mean?

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)