xml-commons charter -Was: xml-commons-which: new Which utility to replace EnvironmentCheck; Gump update request

[David Crossley <cr...@indexgeo.com.au>]

On Wed, 12 Dec 2001, Jeff Turner wrote:
> Wohoo..
> 
> On Tue, Dec 11, 2001 shane_curcuru@us.ibm.com wrote:
> > I've gone ahead and 'bent' the new code rule for xml-commons

OK, it will help to kick-start the xml-commons project anyway :-)
It looks as though this list volume is starting to increase, so
future "new code" additions can be discussed. I gather that
that is what you meant.

Jeff continued:
> Anyone in favour of officially making xml-commons' charter closer to
> jakarta-commons?

What needs to change? Do you see something specific?

Can we replicate and tweak their charter, and add certain bits
from cvs/xml-commons/README.html ? The jakarta-commons
charter has well-numbered items which will help us to discuss
any issues here.

When we have the shell of xdocs in CVS, then we can all help
to flesh them out.

> I have a utility[1] I think would complement Norman
> Walsh's Catalog code..
> --Jeff
> [1] 
http://opensource.socialchange.net.au/doctypechanger/latest/apidocs/

We are keen to see both utilities arrive on xml-commons.

I am here to help with documentation and user experience
viewpoint. With a big start from Davanum Srinivas, i managed
to get the Entity Resolver component hooked up as a Cocoon
component, and start the documentation. That is now in the
xml-cocoon2 CVS and made it into the 2.0 release.

Norm's entity resolver and the SocialChange doctypechanger
are both crucial XML tools. Anything that we can do to assist
their uptake is a good thing.

Anyway these topics are for other threads. The first task is to
start getting the charter sorted. That will take a while and should
not hold up any real work.

(Would the next poster please fine-tune the email Subject.)

--David Crossley

Re: xml-commons charter

[Jeff Turner <je...@socialchange.net.au>]

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
growth.

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
Doctypechanger?

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]..


--Jeff


> --David Crossley