[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX Future

  • From: David Brownell <db@E...>
  • To: "XML Developers' List" <xml-dev@i...>
  • Date: Tue, 17 Nov 1998 12:19:21 -0800

the future of sax parser
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
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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.