Hi Andy,
In describing the current status of the Xercen, you wrote:
> the individual
> parsers are not sub-projects in the XML project and they
> should not be sub-projects in the new Xerces project.
Perhaps we need to straighten out terminology. In the official sense of
the terms as used by, for instance, the XML charter, the XML project is a
Project of the Apache Software Foundation. The entities under XML are
Subprojects of the XML project. Are Xerces-C, Xerces-J and Xerces-P
Subprojects in an official sense? I think they demonstrably are. But I'm
very curious to know what your sense is as to their current status.
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]
04/02/2004 01:55 Subject: Re: [VOTE]: motion to
transform Xerces into a top-level project as a
AM member of the "federation" of XML
projects
Please respond to
general
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
