Neil Graham wrote:
I guess the problem I have with it is that, to me, a sub-
project should be related to a parent project which has
some physical code.
What's the "physical code" in the XML project to which all the Xerces-*,
Xalan-* et al are related to?
There isn't any. Which is exactly why the individual
parsers are not sub-projects in the XML project and they
should not be sub-projects in the new Xerces project.
Pretty much the same kind of thing that is their parent now. Except under
this proposal there's the commonality of "intimately related to XML
parsing" binding the subprojects together; in XML, it's some vague
association with XML or its applications.
Can we just say that and keep the organization of the
parser implementations the same? Then real sub-projects
of the parsers have a place to live within the project/
sub-project architecture.
I wonder if you had a chance to glance at my proposal on how to modify the
charter to permit "closely related" technologies. I'd actually prefer to
The proposal would need to be fundamentally changed
before I could make suggestions about this point. And
if the proposal is changed then it's probably not an
issue anymore.
keep us doing parsers, and have components like HTML parsers live in
XML-commons (or some other more common place), but I thought this might
address your need.
Hmmm... I guess it *could* be a "common" type thing but
it seems more of a Xerces-* sub-project. For example,
the Xerces-J parser could have an HTML sub-project that
includes the HTML DOM and an HTML parser built on the
XNI foundation.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
