Hi folks, A long time ago (back in July, I believe), there was a thread on this list where Shane and I discussed, among other things, how the need for a TCK-compliant set of API's fit in to commons. Since there wasn't really a stable set of TCK-compliant API's at that point, discussion died off for quite a while. Finally, we in Xerces-J think we've assembled a set of JAXP 1.2 TCK-compliant API's that is stable, and so it's time to decide how these fit into commons. Once this is done, I think Xerces will migrate towards pulling our API's from commons (though we'll in all probability continue the nasty habit of repackaging them ourselves into our own API jar :) ). But this will, finally, guarantee that Xerces and Xalan (and whoever else picks this code up) will be in lock-step viz. API support.
Anyway, to open discussion, here are my current thoughts on what could be done. Note that these have changed a bit since July. 1. "up-to-date" API's should remain at CVS HEAD. The TCK-compliant code should go on a branch; perhaps named something like jaxp-1_2_0? The current RIVERCOURT1 branch could perhaps be renamed (and updated) to serve this purpose. (This allows us to fork a new TCK branch off of HEAD whenever JAXP next versions.) 2. The DOM interfaces in the TCK branch remain unchanged (that is, identical to what's at HEAD at the moment). 3. The SAX and JAXP parsers code should be sync'd up with what's in Xerces. The code in Xerces is TCK compliant, and fixes a number of class-loading and filename-uri conversion bugs that aren't addressed in the "up-to-date" API's; that's why I keep putting quotes around that designation. 4. javax/xml/transform/stream/StreamSource probably needs to be reworked to use proper filename-URI conversion code as has been done in javax/xml/parsers/*Factory. 5. For the places in the JAXP and SAX API's that call for fallbacks, in the TCK-compliant code we either need to (a) decide Xerces and Xalan will serve as fallback implementations, inviting other folks who pick up the API's to modify them appropriately if they don't like that; or (b) modify the code such that we can have our build scripts insert an appropriate fallback, in the same manner as they update our Version info; or (c) Continue to punt on fallbacks. I think (a) would be best, since this code will probably be used mainly by Xerces and Xalan, which are the RI for JAXP 1.2 after all. (b) would be fine with me as well, though it's unclear how Xalan would automate this. 6. We need to decide on how the product of the TCK branch and the product of HEAD should be named so as we don't end up with different, simultaneously "current" versions of the same jar file. My preference here would be for the TCK code to use the name xml-apis.jar, since it seems to me that's commonest practice at the moment, and to have the HEAD code use some other handle. Since I have no doubt that this note will garner feedback, so that the TODOs will probably change, I won't volunteer for anything specific now. But this is something I'm committed to, so once we dot the I's and cross the T's, I'll definitely be up for helping with the implementation. Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED]
