Hi Andy,
> Very simply: the draft charter defined Xerces sub-projects
> as parser implementations in different languages. And it had
> no allowance for sub-projects for a particular parser impl.
That's true, though I had revised it to permit subprojects of "closely
allied technologies".
> I don't see any problem with have a PMC that deals with all
> Xerces implementations but still considering the different
> implementations "projects" with their own sub-projects. For
> example, Xerces-J could have an HTML sub-project with the
> HTML DOM implementation and an HTML parser built from the
> Xerces framework.
The idea of subprojects being simultaneously projects with their own
subprojects looks like a terminal terminological disaster to me. :)
Perhaps what we need to get beyond this is the concept of products that
Robert was mentioning exist in other Apache projects. If we said that the
given parser subprojects might have multiple products, where products could
include parsers and components closely tied to parsing, would that solve
the problem?
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
Andy Clark
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
et> cc: [EMAIL PROTECTED], [EMAIL
PROTECTED],
[EMAIL PROTECTED]
05/04/2004 02:09 Subject: Re: [VOTE]: motion to
transform Xerces into a top-level project as a member
PM of the "federation" of XML projects
Please respond to
xerces-j-dev
Berin Lautenbach wrote:
> Note that one does not preclude the other. The decision as to whether
> or not to become a TLP should not rest on the charter, although I think
> it is good to understand how the project is going to run prior to
> starting :>.
Agreed.
> You'll have to pardon me here - what were the exact issues you had with
> the charter? I think there was a piece around top level code base?
Very simply: the draft charter defined Xerces sub-projects
as parser implementations in different languages. And it had
no allowance for sub-projects for a particular parser impl.
I don't see any problem with have a PMC that deals with all
Xerces implementations but still considering the different
implementations "projects" with their own sub-projects. For
example, Xerces-J could have an HTML sub-project with the
HTML DOM implementation and an HTML parser built from the
Xerces framework. But the draft charter was explicit about
defining a sub-project as an XML parser implementation in a
particular language.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
