-CORRECTED VERSION - Report on a Workshop on Xerces-j hosted by the ASF/XML project

[Dirk-Willem van Gulik <di...@covalent.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Report on a Workshop on Xerces-j hosted by the ASF/XML project
	on the 16th of October

	Version 1.01

	*	Corrected version - unfortunately due to travel
		and crossing email I missed some of the comments
		made on a draft circulated among the workshop
		participants. This final report should take all
		comments into acount.

Subject:
	Xerces-j Projects 

Invited:
	xerces-j-dev@xml.apache.org
	general@xml.apache.org
	members@apache.org
	pmc@xml.apache.org

Host:
	The ASF/XML project
	
Location:
	Meeting room provided by Covalent Technologies
	706 Mission street 2nd Floor

Present:
	Chuck Murco 
	Jason Hunter 
	James Duncan Davidson
	Jim Driscoll
	Edwin Goei
	Arnaud Le Hors
	Andy Clark
	Ted Leung (by phone)
	Sam Ruby (by phone)
	Dirk-Willem van Gulik 

It was recognized that all present where effectively representing both
their respective employers as well as representing a sizable chunk of the
active members of the ASF's xml-xerces-j project. There is some inherent
conflict in this - an issue which is common across all ASF projects.

The xml-xerces-j project is currently seen shifting their focus towards a
'future' parser. This has caused a number of factual engineering, as
well as perceived, differces of opinions. Some of which caused
consternation within the member's their respective employers.

It is important to take away those concerns. Part of this is broadening
the developer base. Although a more welcoming attidude towards new
developers might help it is also fair to say that the current xerces-1
code base is complex to understand and that the current -dev mailing list
carries a lot of -user traffic.

As in any engineering project - it is recognized that the design for the
new parser will have to make tradeoffs. The current charters of the ASF
and the XML project offer some guidance. The following three properties
are considered inportant, and in this particular order:

	Specification Compliance
		and feedback to the working group(s) setting
		those specifications. 

	Modular, Readablility

	Performance, Footprint

It is also noted that a moduler design with a good interface design 
would allow people to change those tradeoffs, for example by 
swapping in compatible parsers.

One discussion which needs to happen in due time is a charter discussion;
do we need to embed some of those requirements into our charter, and how.
And do we want to juggle some of the tradeoffs. Another item which needs
attention is dead code and other cruft in the current tree. It should be
clear from now on that any (larger) code contributions is only to be
accepted if there is a clear maintenance path. Traditionally, within the
http project, a '+1' vote on such a contribution should also lead to some
joint responsibility later - when the original contributor is perhaps no
longer active - and that code needs maintenance. We also should work out
how we deal which such dead code. In general there are a lot of similar
code management issues, which could be used to elaborate on and refine 
the charter.

Next the group discussed xerces-1, the xerces-2 branch, the requirements
documents and crimson. Measured against the above goals it was generally
agreed on that xerces-1 has no clear future, that crimson could not be a
that future either; and that we should start focusing on xerces-2 now. A
lot of groundwork has been done, requirement documents are actively worked
upon, there exists comparisons and 'lessons learned' documents of xerces-1
and crimsion and even a branch in the xerces-1 tree. 

It is now just a matter of making all that visible in one place and start
getting some traction.

Right now we have a flat commit model across all xerces projects - any xerces
commiter can commit to any xerces project and the web site. This is felt as
something we should stress and capitalize upon. And something which will
actively help us transition and re-focus develeopers towards on
xerces-2. But at the same time we should update the web site to guide
people towards xerces-2 for new work and make the history behind crimson
and xerces-1 clear. Though we should not be putting any hurdles in the
way of people who want to maintain either of the old projects - the
meeting really wants xerces-2 the place to be.

Secondly xml-contrib should be as liberal a staging ground and stepping
stone as possible. Where things like treedif can live and worked upon for
example. It is suggested that we document xml-contrib and make it as
welcome and as easy to get 'into' as the original 'incoming' of the apache
httpd project.

Suggested actions

1	Move the current xerces-j-dev@xml.apache.org group
	into xerces-j-users. And create two new groups,
	xerces-j-dev and xerces2-jdev.

	The reason for this is twofold - the current -dev list
	has a large volume of user traffic; and we want to
	clearly focus the -2 traffic.

	-> This would need to be voted upon. When agreed to be
	   done by duncan/dirkx.

2.	Move crimson out of xml-contrib and give it
	a historic status and a repository of its own 
	- which is documented and pointed to from the 
	website. And clearly labeled this as a 'dead' 
	code line - and urge any one who wants to work 
	on xml parsers to make contributions to the Xerces 2

	Any discussion should be carried out on general.

	-> needs to be voted upon. 

7. 	Move the xerces-2 branch in xerces-1 to a repository
	of its own; xml-xerces2. And label xerces-1 as
	an effective dead end - which is there to be maintained
	but not further developed. Instead people are
	urged to work on Xerces 2

	-> needs to be voted upon. 

3.	Create and posting a FAQ on the (new) xercjes-j-users
	mailing list.

	-> needs to be voted upon. 

4.	Rearranging the web site to make the historic/maintenance
	only status of xerces-j/crimson clear, make xerces-2
	clearly the track for the future, and aggregate the
	current requirements docs, comparison and other docs
	all in one place. Where needed this will simply be
	mapped directly into the (source) tree's - and thus
	bypass the current xml->html engine. 

	-> needs to be voted upon. 

5.	Prepare document on how to insert xerces 1&2 into the new JDKs

	-> to be prepared and submitted.

6.	Document the fact that we want general@ and xml-contrib
	as open as possible - for anyone to park a cool idea.

Timeline

It is suggested that the above items are brought to vote on the
mailing list as soon as possible; and if possible so that some
of this can be announced or discussed during the apache con. Dirk
will request a soap-box moment during one of the (ASF) plenaries
which would allow someone from the xerces-j community to stand up
and talk for 5mins about where we are.



-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOfFQI/1viMYh0KcbEQIlpwCgwZfjJuxk7daYG5qoPEugjbOECxkAn3NK
SlWVA3wYfQx6x8iqDIbgf5qn
=rOvj
-----END PGP SIGNATURE-----