OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   JSR 206 and SAX

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: JSR 206 and SAX
  • From: Norman Walsh <ndw@nwalsh.com>
  • Date: Wed, 18 Feb 2004 16:48:58 -0500
  • User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Dear developers,

As one of the specification leads for JSR 206, developing JAXP 1.3, I
find myself in a very uncomfortable position. I seek your counsel.

One of the requirements that we took on for JAXP 1.3 was support for
XML 1.1 and XML Namespaces 1.1. In order to support those
specifications, it became clear that some changes would be needed at
the SAX level, for example, in order to report the XML version of the
document parsed.

We met with significant public criticism when we initially suggested
that JAXP might modify the SAX APIs in order to support our

Fair enough. We were persuaded, easily I think, because we all want to
be good net citizens, to adopt an alternate approach. Instead of
changing the APIs, we would take advantage of the SAX extension

That seemed like a workable plan and I turned my attention to
overcoming a small process hurdle. In order for us to use the
extension framework in JSR 206, we needed to get its status upgraded
From "beta". Given that the API had been public for a long time
without any changes, I didn't imagine that that would be too

In fact, I have had remarkable difficulty eliciting any response from
the readers of the sax-devel list or David Megginson or David
Brownell, the only individuals with committer status on the SAX

So just recently, when Michael Glavassevich pointed out[1] on the
sax-devel list why the extension framework is insufficient for our
needs, I became deeply concerned.

For better or worse, a JSR is not simply a specification exercise. We
must ship a reference implementation. To make matters worse, a hard
deadline has been imposed on JSR 206. So we have significant,
practical challenges to overcome in a fairly short period of time.

I don't know what to do and neither, as far as I can determine, do the
members of the expert group.

A number of possibilities occur to me, none of them very attractive:

1. We could decide not to support XML 1.1 and Namespaces 1.1. The changes
   in XML 1.1 are small, the RI team has worked to address them, and
   the specifications are now recommendations. I think the argument that
   we should abandon our position of supporting them because a few changes
   are needed in the SAX API would be a hard sell.

2. JSR 206 could fork SAX, producing javax.xml.sax.* classes, for example.
   This would be "honest" in the sense that we would not be changing an
   API that we are not empowered to change. But it would be bad.

3. The developer community could endorse our EG to make the few small changes
   needed to SAX to support XML 1.1 and Namespaces 1.1. Unlikely, I fear.

4. The developer community could modify SAX to support XML 1.1 and
   Namespaces 1.1. That would be best, but I'm uncomfortable with the prospect
   of achieving that within the schedule I have to meet.

There may be other courses of action, but those are the four that
occur to me this afternoon.

I sincerely want to "play well" with the developer community. I like
to imagine that I'm part of that community and that the work I'm doing
is of general benefit. I'm under considerable pressure to deliver JSR 206,
complete and on time.

What do you, as both the developers who helped to craft SAX and the
developers that I imagine are likely to want to use JAXP 1.3, think is
the right course of action?

Speaking for myself, and not officially for the EG,

[1] http://article.gmane.org/gmane.text.xml.sax.devel/151
Norman Walsh <ndw@nwalsh.com> | One does what one is; one becomes what
http://nwalsh.com/            | one does.--Robert Musil

PGP signature


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS