xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: xml-commons charter
Date Wed, 12 Dec 2001 09:51:15 GMT
On Wed, Dec 12, 2001 at 07:37:14PM +1100, David Crossley wrote:
> Jeff continued:
> > Anyone in favour of officially making xml-commons' charter closer to
> > jakarta-commons?
> What needs to change? Do you see something specific?

This paragraph from xml-commons/README.html:

  New modules generally shouldn't go in until at least two separate
  other projects express interest in using the module. I think this is
  an important difference from jakarta-commons that makes sense in our
  world. I.e. I'd rather not just throw something in because it seems
  like it might be useful, I'd rather only put things in that we know
  will be shared among multiple projects.

This excludes all code developed by "third parties", outside the
jakarta|xml.apache.org world.

Does this matter?

Well if you look at jakarta-commons, *most* of the code comes from
outside Apache. Eg, someone developed a utility for a commercial
project, and wants to give it a larger audience. Exactly my situation
with DoctypeChanger.

So I think the "until at least two separate other projects express
interest in using the module" clause will rather limit this project's

But then, is this a bad thing? There's no reason XML-specific utility
code can't live in jakarta-commons.

Only justification I can see is that:

 - Jakarta has a server-side focus, whereas xml.apache.org doesn't
   (AFAIK). jakarta-commons reflects that server-side focus, and could
   conceivably object to client-side XML utilities.
 - xml.apache.org is language-neutral, jakarta.apache.org isn't.
   xml-commons could accept a C/C++ catalog implementation, whereas
   jakarta-commons wouldn't.

Another question: what projects do people *want* in xml-commons anyway
apart from DOM/SAX/JAXP, Catalogs, Shane's env checker and possibly

Personally, I think stripped-down, highly focused Cocoon-based apps
("spinoffs") would be a good idea. Cocoon is dynamite, but it's too big
and general. I'm thinking:

 - separate out and package the Avalon/Cocoon documentation system, used
   to generate websites, PDFs, SVG->jpgs, etc. All very cool stuff to
   have in any project. Cocoon-generated website-in-a-box :)
 - Cocoon "powerpoint"-style presentation generator. There's some XSPs
   in Cocoon somewhere, but we could "productise" it, so anyone can fish
   the template out of CVS and start editing slides immediately. 
 - As above, but for creating resumes.

Ovidiu Predescu has a groovy set of Ant tasks called "Anteater", for
unit-testing servers, with a heavy focus on XML and SOAP. xml-commons
would be a good home for this too.

So in summary, I think there's plenty we *could* do, and I think the
above has a sufficiently different "flavour" to jakarta-commons to
warrant a separate xml-commons project.

What do people think? Especially the founders of this project.. here's
this bunch of new kids, walk in and start changing charters... ;) If
there's interest, I can modify README.html and call a [VOTE]..


> --David Crossley

View raw message