[snip]
Categorizing Xerces is difficult because of the fact that we have implementations in different languages that are parallel in function but don't share design or implementation, as you've stated. And there aren't many Apache projects that are similar in that respect. So we need something very different than most of the existing Apache TLPs.
How do you feel about settling on the following terms:
* project: the top level project (TLP) * sub-project: a functional category related to the TLP * product: a specific implementation
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.
How does that structure strike you?
I have trouble accepting the idea that the WML DOM implementation that got dumped on Xerces-J all those years ago has much to do with Xerces-P...
You're right, it doesn't. But WML "parsing & APIs" are language independent concepts. It's just that we only have a single implementation: Java.
And so are XSLT processing and XML Security work... I'm not necessarily opposed to bringing something like an HTML parser into the Xerces fold, but it does seem you could argue it both ways.
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. (Assuming the community wants it.) So I want to make sure that there's a clear home for it within the new TLP structure. And it's my assumption that it would be grouped together with the HTML DOM implementation.
them products of Xerces-J, subsubprojects of Xerces-J, or put them in a sandbox or Xerces-commons area composed of componentry closely
That's an interesting idea but I think it dilutes what's offered and makes it more difficult for people to pull out the specific tools they're looking for -- we'd just be moving the big grab-bag down one level.
allied to XML parsing, it's all good. The only point I'll have to stick to is that there isn't some magical Xerces entity that contains all the components of Xerces-* that are considered "core" to parsing.
Agreed. The distribution would still be separated by the implementation language, just as it is today.
-- Andy Clark * [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
