<snip>
I consider all the parser implementations as "Xerces", the TLP. They are built, packaged, and shipped separately but I still consider them all the same thing at that level. With that view, Xerces-* are all "Xerces".
And I think it's imperative that we create a charter that recognizes what I
take to be a crucial fact, which is that Xerces-J and Xerces-C are very
different code bases with different architectures and committer
communities, and, to some extent, which have been optimized for differing
uses. We need a charter that formalizes our long-standing process that a
committer on one project is not considered automatically to be a committer
on the others.
one of the most interesting facts about the social experiment that is jakarta commons is that an lot of people thought that it'd never work without barriers between components. but the pmc decided to experiment with a minimalist approach - there is only one set of commons committers who have rights to the whole. the only requirement is that before starting to commit to a particular component, a committer must add their name to the list of those who are responsible for that component.
what's amazing is that the lack of formal restrictions makes everyone more conscious of the need to co-exist together as a social community. the boundaries between components seem to be are respected (by the community) more because they are not formal rules but living social conventions. so maybe if the devision is already recognized socially (by the C and J communities), there may be no need to actually formally specify it (in the charter).
of course, this is just my tuppence :)
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
