xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Curcuru/CAM/Lotus" <shane_curc...@us.ibm.com>
Subject [discuss] Versioning strategy for standards files: SAX/DOM/JAXP
Date Sun, 30 Jun 2002 01:39:48 GMT
<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="curcuru@apache.org">
<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/item[@num="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/item[@num="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/item[@num="2"] now, and perhaps would
be updated later to meet JAXP 1.2, etc.  Then the main trunk would be for
proposal/item[@num="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>




Mime
View raw message