Hi Andy,

> The way I
> look at it, the Xerces parsers in all languages comprise
> the "Xerces" project. They may be built and packaged
> separately but that doesn't mean that they're separate
> sub-projects.

But they do seem to have quite a number of the characteristics of
subprojects:  their architectures are quite vastly different (especially
Xerces-C and Xerces-J 2, the most active); with a few exceptions their
committer bases are disjoint--and in the two cases I'm aware of in which
this isn't true, including yours truly, the committers in question are
pretty inactive on both at the moment :)--and their users are pretty much
disjoint.  So even if this isn't the situation we'd hoped for, it's the one
we have and its existed for long enough that I'm not persuaded it's likely
to change.  So I'd like to recognize it and codify it in our charter, since
that seems the easiest thing to do administratively.  Not to mention having
some nice side-effects of clarifying how decisions get made, and providing
at least a link via the PMC between everything.

> Then, the Xerces sub-projects would include proper sub-
> projects of the parser. For example: the HTML and WML DOM
> implementations; perhaps an HTML parser built from Xerces;
> a Relax NG validator; etc.

Here my views are much less clear-cut. As currently worded, I think these
types of animal would only fit into existing subprojects, and so would have
to be adopted.  Perhaps we need to loosen our definition of what we're
about  by changing 1.1 to read, in part

[[
1.1 Apache Xerces is a collaborative software development project
dedicated to providing robust, full-featured, commercial-quality, and
freely available XML parsers and closely related components on a wide
variety of platforms supporting
several languages.
]]

and perhaps 4.3 needs to look something like

[[
4.3 Subproject.  Apache Xerces is comprised of a number of subprojects,
corresponding to each of the languages for which a parser has been
produced, or to significant, discrete components that closely rely on the
parser and whose function is in some way allied to XML parsing.  Currently,
there are parsers for Java, C/C++ and Perl.
]]

Does that meet any of your concerns?

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]            
                                      
                      >                        cc:       [EMAIL PROTECTED], [EMAIL 
PROTECTED],               
                                                [EMAIL PROTECTED]                      
                                         
                      03/31/2004 01:02         Subject:  Re: [VOTE]:  motion to 
transform Xerces into a top-level project as a   
                      PM                        member of the "federation" of XML 
projects                                       
                      Please respond to                                                
                                          
                      xerces-j-dev                                                     
                                          
                                                                                       
                                          
                                                                                       
                                          



It looks good except for the part about the parsers in
different languages being the sub-projects. The way I
look at it, the Xerces parsers in all languages comprise
the "Xerces" project. They may be built and packaged
separately but that doesn't mean that they're separate
sub-projects.

Then, the Xerces sub-projects would include proper sub-
projects of the parser. For example: the HTML and WML DOM
implementations; perhaps an HTML parser built from Xerces;
a Relax NG validator; etc.

Thoughts?

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

Reply via email to