[DISC] Proposal: new xml-core project for standards-based files

[Sh...@lotus.com]

I propose a new xml.apache.org subproject to fulfill the need for a central
repository for various XML standards-based files.  Comments on this
specific proposal please, everyone! (not like I really have to ask... 8-)

<xml-subproject-proposal-commons-v1.0/>
(0) Rationale:
Many xml.apache.org projects use and ship with sets of similar
externally-defined standards-based code; differences in versioning and
configuration of this code often make developing and especially using our
projects more difficult.  A common place for all xml.apache.org projects to
get DOM, SAX, JAXP, and other externally-defined code would be a fairly
low-cost and low-maintenance way to alleviate these difficulties.

(0.1) Java/C/Perl/etc note: The details in this proposal pertain to
Java-based projects; I believe the basic idea may be worthwhile for other
language versions to use as a framework for their own discussions.
Directory structure could include /java /c /perl /other?


(1) Scope of this subproject:
Beginning scope to contain common externally-defined standards, including
the packages: org.w3c.dom.**, org.xml.sax.**, and javax.xml.**  This is
designed to essentially be an xml.apache.org-specific holding place for
commonly-used files that are created outside of Apache.  This subproject
should provide guidelines and build scripts to aid xml.apache.org groups to
easily use these common files in a common manner across all projects.  This
subproject should provide some basic versioning abilities so that
xml.apache.org projects temporarily using new/beta/updated/proposed
versions of these specs can continue to get their code from this area.

(1.2) Potential Additional Scope of this subproject:
An obvious addition would be to also include additional utilities/common
code in this subproject, like current copies of bsf.jar, stylebook, servlet
API classes, etc.  This could also include code that did originate in an
Apache project, that we wanted to centralize the use of: SystemIDResolver,
XML Serializers, etc.  This part of this proposal is very much like the
jakarta-commons proposal; however if it proves controversial or difficult
to implement, I'd recommend dropping this portion and implementing the rest
first.

(1.3) Non-scope of this project:
Note this is primarily a subproject to make life inside of xml.apache.org
easier.  A common recent discussion thread about a potential AXDK (Apache
XML Development Kit) that would be a meta-project composed out of several
xml projects together would be separate from this (and would primarily
address end-users ease-of-use of xml projects).

(1.5) Interaction with other subprojects
Guidelines need to be drawn up on general@xml.apache.org for the use of
this subproject, and then documented and checked in.  These should include
both how other xml subprojects should use these resources in their
development cycles, as well as how all xml subprojects should package these
resources when creating public, shipped distributions (to avoid version
conflicts, etc.)


(2) identify the initial source from which the subproject is to be
populated:
Sources would be obtained from the relevant owners/creators and checked
into the project repository. A basic build.xml file and apache project
usage guidelines would need to be created.  Possible legal review would be
needed for licensed files (one solution might be to waive the Apache
license on these files).


(3) identify the xml.apache.org resources to be created

(3.1) mailing list(s)
xml-commons (or name of project)

(3.2) CVS repositories
xml-commons

(3.3) Bugzilla
program - commons


(4) Identify the initial set of committers
Hmmm - here I'm not sure what's best.  I'll try to limit the choices.
(4.a) Proposal?: kellyc, curcuru, rubys
(4.b) Proposal?: one committer from each xml.apache.org subproject that
wants to volunteer, plus at least one PMC member (for projects that don't
get someone volunteered)
(4.c) Proposal?: one member from each xml.apache.org subproject


(*) Important cross-reference:  http://www.husted.com/about/commons/
Jakarta is currently working on a similar, yet different, tool/util/common
code area.  While we can steal a lot of their ideas, I think the needs of
xml.apache.org will be different than Jakarta, so we should make our own
community decision on how to do this.  Many thanks to the nice format for a
proposal that I plagarized.  8-)


- Shane (also-discuss-with @ Tuesday Hackathon/ApacheCon next week)

(Meta-Notes: [DISC] = let's discuss this targeted proposal for a while.
This obviously needs buy-in from the community, and I don't think it's
quite right yet, so I'm hoping the community can help me figure out what is
right.
Targeted: I'd like to try to categorize and target some of the discussions
on general@xml so we can make better progress without everyone being lost
in the maze of email threads; hence I'll try to keep this particular thread
on subject.
Also, I specifically tried to keep the scope of this proposal small, so we
might agree and implement it more quickly; if we want to add more things
later we can update it as we go along.  But I think it would be useful to
actually implement and use this for a while before deciding on the
organization of a larger shared kit.)


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

Re: [DISC] Proposal: new xml-core project for standards-based files

[Martin Stricker <sh...@gmx.de>]

And another snippet mail... (whew, I missed quite much this week!)

=======================================================================

Shane_Curcuru@lotus.com wrote at Fri, 30 Mar 2001 16:21:40 -0500:
> I propose a new xml.apache.org subproject to fulfill the need for a
> central repository for various XML standards-based files.  Comments on
> this specific proposal please, everyone! (not like I really have to
> ask... 8-)

This sounds like a Really Good Idea! If I understand this correctly you
want two things: 1) A central repository for external code which is not
altered by xml.apache.org. 2) A central repository for code which is
used in more than one xml.apache.org project and is coded at
xml.apache.org.

Both parts should be clearly divided. We certainly should include other
languages than Java. For Perl there are some modules in CPAN
http://www.cpan.org/ which might be useful.

I think especially the second part should be very good for pushing
xml.apache.org to produce not just some single applications but a
framework of bricks (sorry, I can't think of a better English word for
it) that interact via a common xml.apache.org API or interface (like
Scott Boag suggested earlier). This API and/or interface should be
placed in the second repository so all projects can be sure all the
others are using exactly the same than they do. It's a kind of
inter-project standardization.

=======================================================================

Scott Boag wrote at :
> Ah.  I hadn't realized that AXDK was the projects packaging proposal,
> I thought it was the API packaging proposal.  Reading too fast, I
> guess.

> I'm not sure why this couldn't be done by the same project.  A single
> project can certainly put out multiple zips!

I agree. We should have only *one* Common project. I got quite good
results in past and present projects with this approach: Each project
puts code they think is useful for other projects in Common and take
wahtever they can use from there. Of course you have to be cautious
about the interfaces: Never change a Common interface but add a new one
if necessary and maybe deprecate the old (and delete it if you have
assured no one is still using it).

Common solutions for end users might come in handy for development
issues, too. Wouldn't be the first time...

> Maybe xml-commons is the place to do testing utilities also???

> I know you want to limit scope at the start, but it would be nice to
> get these things rolling...

I think in xml-commons should all code be collected that is useful for
more than one project, regardless if it's already used more than once.
And all xml.apache.org projects should search in xml-commons first if
they need new stuff. This will help to standardize our codebases, and
why invent the wheel twice? ;-))

And by saying it has to get into xml-commons it doesn't mean it has to
get in there at once. We'll find our pace of development, don't be
worried...

On an unrelated note: Developing for xml-commons might be another easy
starting point for new developers! BTW the *first* thing we'll have to
do is documenting our APIs and interfaces!

=======================================================================

+1 for the proposal.

Best regards,
Martin Stricker

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org