Neil Graham wrote:
So "Xerces" would be the project whereas "Xerces-J" would
be a product release of Xerces in Java. An example sub-project
would be "HTML" which, again, would have products based on the
implementation language. They would be bundled together for
organizational reasons, not for releases.
Conceptually, the only difficulty I'd have with this is that it's no longer
crystal clear what the commonality between the subprojects is. I'd thought
It's not clear to *you*, is what you mean. It's perfectly clear
to me. ;)
that the "Xerces" TLP would be all about Apache's offerings related
specifically to XML parsing first, and perhaps very closely related
technologies second.
That sounds exactly like what I'm proposing through my use of
the terms "project" and "sub-project". Parsing is the project
and things related to parsing are sub-projects. Products is
the way that the implementations are separated from each other
within the project.
So someone comes to the website looking for XML parsers and
they go the the Xerces Project. Then they decide what language
they need, Java, so they download the Xerces-J product. Next,
they want to be able to parse HTML, so they look at the Xerces
HTML sub-project. There they see that there is an implementation
in Java for use with the XML parser they just downloaded.
In this situation, of course there are things that need to be
broken out of Xerces-J as it stands today. But once that is
done, they are each developed and packaged separately. It's
primarily the website organization that reflects the hierarchy
and relationships between these separate things.
I'm specifically trying to organize the Xerces TLP so that
I can formally donate NekoHTML to the Xerces project for the
Xerces-J product.
I'd been guessing that. :)
I'm asked on a regular basis if/when it will be merged into
Xerces-J so this is a perfect opportunity to do that.
* project: the top level project (TLP), charged with XML parsing
and closely allied technologies
* sub-project: either
o an XML parser implementation in a particular language, or
o a "tools" subproject containing useful products that are
tightly bound, usually by nonstandard API's, to one of the other
subprojects
But this puts dependent products at the same level as the
parser. You would think they would be *under* the parser
because of the dependency.
The tools subproject could contain products from as many languages as there
were parsers. I'm also fine with removing the restriction that we have one
parser per language; we may want a Xerces-J-Pull at some point.
Well, that was certainly one of my biggest problems with the
original draft.
Once again, I'd love to call on other folks from Xerces-land. Andy and I
are having a good time talking among ourselves, but it's tough to gauge the
consensus of a community when you only ever hear two voices...
It does seem rather quiet around here. I'm surprised that
noone else has added their ideas to the discussion. Perhaps
they're scared of me. ;)
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
