xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From shane_curc...@us.ibm.com
Subject Re: [PROPOSAL] javax.xml and javax.xml.namespace package to xml commons
Date Wed, 24 Sep 2003 14:50:51 GMT
Sounds like an excellent idea.  They should live under java/external/src, 
since that's the root of the tree where we keep external standards files - 
i.e. stuff that effectively we are getting interface definitions from 
someone else.

The is exactly what xml-commons is supposed to be for - I just haven't had 
time to follow up on the new QName classes to do it.  I bet Xalan will 
need it soon as well, and we should definitely store a common version that 
everyone uses.  (Xalan currently has two: one clunky one from old XSLTC 
code, and one for Xalan code that includes extra PrefixResolver 

Note: we should be careful when we check in the first version to be sure 
it's correct and best matches whatever we think the standard will be in 
the future.  Be sure that QName is not a final class; one of the early 
versions from Sun was final until people got them to change it.  We should 
also checkin an extra java/external/README.QName.txt file explaining where 
we got this copy and what standard we expect it to be in in the future. 
Also any LICENSE.QName.txt, if one is needed.

Note that while it might seem silly to have all these external files 
copied here, instead of everyone getting them from the master 'sources' 
(i.e., getting DOM files from W3C, etc.) this allows the ASF to have it's 
own central copy of important standards that we can modify.  Often JCPs or 
the W3C take a long time to update standards, and we may find bugfixes at 
any time.  Having our own copy lets us fix bugs in real time, and then can 
let us submit the working fixes back. 

Also, the HEAD of xml-commons can be the latest-and-greatest of any code - 
as long as it works, and is in the sprit of whatever external standard it 
represents.  Xalan and Xerces also have a branch, tck-jaxp-1_2_0, which we 
are using to track bugfixes that specifically will pass the JAXP 1.2 TCK. 
Since the ASF has access to the TCKs, we can (and should) ship software 
that actually passes them when we implement appropriate JCP'd software.

- Shane

View raw message