xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ne...@ca.ibm.com
Subject making TCK-compliant API's common
Date Wed, 13 Nov 2002 16:34:01 GMT
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
4.  javax/xml/transform/stream/StreamSource probably needs to be reworked
to use proper filename-URI conversion code as has been done in
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;
(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.

Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com

View raw message