[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] JSR 206 and SAX
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 requirements. 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 framework. 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 difficult. 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 project. 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, norm [1] http://article.gmane.org/gmane.text.xml.sax.devel/151 -- Norman Walsh <ndw@n...> | One does what one is; one becomes what http://nwalsh.com/ | one does.--Robert Musil
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|