Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3C1933EE.D7644248@gmx.de>
Date: Fri, 14 Dec 2001 00:04:14 +0100
From: Martin Stricker <shugal@gmx.de>
Organization: http://martin-stricker.de/ http://www.surfo.net/
 http://www.masterportal24.com/cgi-bin/YaBB.cgi
MIME-Version: 1.0
To: general@xml.apache.org, commons-dev@xml.apache.org
Subject: Re: xml-commons charter
References: <20011212114234.5194.qmail@web12102.mail.yahoo.com>
 <3C17DCC3.95810C7C@gmx.de> <3C17F64F.DD0387C5@dbxmlgroup.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Bradford wrote:
> 
> Martin Stricker wrote:
> > A repository of XML and XSL tools, maybe called "xml-tools", should
> > be kept separate from xml-commons. I see xml-commons as a
> > inter-xml.apache.org project, and a tool collection definitely would
> > target more on users than on xml.apache.org subprojects. And if
> > something from xml-tools becomes used by some xml.apache.org
> > subprojects it always can be moved over to xml-commons.
> 
> I agree with this.  The reason we're using the xml-commons stuff is to
> be sure that our DOM, SAX, and JAXP classes/interfaces will
> interoperate smoothly with other projects.  Anything beyond that may
> be something that we've duplicated or that we don't need, and should
> be kept part of a separate project... Though, it would be nice if some
> of those common utils could become part of an xml-tools project.

This would of course work nicely: xml-tools would just as any other
xml.apache.org subproject be *encouraged* to use anything useful from
xml-commons. To ease development no xml.apache.org subproject should use
code from anywhere but it's own repository and xml-commons. If any code
is in use by more than one subproject this is the clear sign this code
has to be moved to xml-commons asap.

One *could* put stuff in xml-commons which is *expected* to be used in
more than one subproject, but from my personal experience (both
programmer and project manager) I found this usually leads cluttering up
the common repository with maybe useful stuff so no one dares to dig in
that mess, making the common useless. OTOH it's quite easy to move stuff
from one project's repository to common and get it at build time.

Another idea which has proven itself useful is a "providing" and a
"searching" document for each subproject where possibly reusable code
can be advertised. Looking through these documents provides easy
detection of possible synergies for the project manager or anyone in one
of the subprojects.

Just some assorted thoughts...

Best regards,
Martin Stricker
-- 
Homepage: http://www.martin-stricker.de/
Registered Linux user #210635: http://counter.li.org/