<doc> Here's a starting proposal for better version management of the standards-based files in xml-commons' external directory. Although I've passed these ideas by a few Xerces and Xalan folks, we need community feedback on this issue.
<proposal ver="1.0" author="[EMAIL PROTECTED]"> <item num="1">Actively manage and document the file versioning strategy for xml-commons/java/external.</item> <item num="2">Maintain one primary 'branch' (term used loosely) of files that specifically track and pass the appropriate TCK's for JAXP 1.1 and related tests. These files would be used to create a distribution of xml-commons (and xml-apis.jar, etc.) that can be used by any products who need to integrate with TCK or specific-server-version environments. For example, JDK vendors and servlet engines may wish to be J2EE 'compatible', which probably includes passing the JAXP 1.1 TCK; this version of xml-commons would be for them.</item> <item num="3">Maintain one alternate 'branch' (term used loosely) of files that are regularly updated to match the latest-and-greatest versions of any officially shipped versions of standards files. This version of xml-commons would be for any other projects who simply want the latest standards, and don't care about passing particular TCKs for whatever reason.</item> <item num="4">Document procedures and find volunteers to track SAX/DOM/JAXP standards, both to ensure new versions get triaged for checkin to xml-commons and to pass back any bugs found in Apache versions of products to the original standards owners.</item> </proposal> <background> xml-commons is an unusual project because it partially includes externally-defined standards files - SAX/DOM/JAXP - which not only originate outside of Apache, but are also critical to most XML processing. It turns out that a large number of projects actually have very specific versioning requirements, some of which are not obvious. Thus, we should agree upon a versioning strategy and clearly document it so that any other Apache (or other!) projects who wish to use our code or xml-apis.jar can have a simple and central place to get this code. I see two main clients for our standards files: -- JDK teams, servlet engines, J2EE containers, etc. These groups want XML parsing/processing, but they also need to pass a number of Sun-defined tests to get various certifications, etc. This is a clear need that we haven't always been meeting in an organized fashion, partly due to resource issues, and partly due to general confusion about how the TCK's and the like work. proposal/[EMAIL PROTECTED]"2"] is designed to meet this need. With just a little bit of effort and documentation, we can easily produce xml-commons distributions that provide this. Once we better understand how the TCK's work, we could even make selected fixes and updates to various implementations of standards files (some SAX fixes come to mind) that will still pass the TCKs (which partly only test method signatures). -- Various other projects who simply want the latest and best of everything. There are plenty of projects who don't seem to care about TCK compatibility for whatever reason, but want access to the latest versions of files. This would be met by proposal/[EMAIL PROTECTED]"3"] which can track the latest SAX 2.0.1 and could even make proactive fixes or updates that Apache projects found useful, which could then be passed back in an organized fashion to the original standards authors. Hopefully, this could serve as a model of collaboration between multiple Apache projects and the various external standards groups and could make our xml projects a little cleaner, by reducing class version conflicts and having a single set of sources for SAX/DOM/JAXP files. </background> <issues> <issue num="1">Which 'branch' would be which? Shane proposes to make a 'TCK' branch that would meet proposal/[EMAIL PROTECTED]"2"] now, and perhaps would be updated later to meet JAXP 1.2, etc. Then the main trunk would be for proposal/[EMAIL PROTECTED]"3"]. Why? Because the trunk already has SAX 2.0.1 checked in, and because for me the trunk should be the latest-and-greatest. But several others have argued the reverse, so we need to get consensus.</issue> <issue num="2">Better understanding and procedures for which TCK's we need to support, and exactly what they test. I think that a number of the IBM committers on Xerces and Xalan may be able to help cover this issue, since some of us already have experience in this area (sadly, Shane is not one of them yet...)</issue> <issue num="3">Actual packaging of standards files. xml-commons currently produces an xml-apis.jar as per our earlier vote that includes the full tree of SAX/DOM/JAXP files; this is used as-is by Xalan in a formal manner and informally by other projects. Xerces uses their own xmlParserAPIs.jar file in a slightly separate procedure. And a few people have come back to the old proposal for separate dom.jar/sax.jar/jaxp.jar files. Note: the actual packaging is really a separate issue from versioning strategy, so please, let's argue that one separately!</issue> <issue num="4">Coordination with other Apache projects, both xml and jakarta. If we can agree on a clear strategy and document it, I'd hope to see the majority of Apache projects that need xml processing simply get their files from xml-commons (or thru Xerces/Xalan, of course). This will take some work on documenting and publicising what xml-commons produces and some consensus building as well. (Plus possibly getting GUMP to run two xml-commons builds, one for each 'branch')</issue> <issue num="5">Coordination with various dependent Apache projects, especially for ones with GUMP runs and/or who would want to provide builds from both 'branches' of xml-commons (one backlevel TCK one, the other latest-and-greatest one).</issue> </issues> Note that this proposal only affects the xml-commons/java/external tree; it in no way impacts the small selection of Apache-based xml utilites rooted at xml-commons/java/src. - Shane </doc>
