Elena Litani wrote:
I am OK with the idea of *adopting* Neko and Jing, however, I would like to see those as sub-projects.
Agreed. And we should break out the HTML DOM, the WML DOM, and the serialization code at the same time.
1. What is the criteria for creating a sub-project? Should we consider
how many committers are interested and willing to work on the
sub-project, should we consider user requirements? Where does the vote
take place, i.e. xerces-j-dev, xerces-j-user?
For some protential sub-projects (e.g. NekoHTML), there aren't more than a single developer. But there is enough interest from the Xerces user community to warrant its inclusion. So as long as code comes with a single contributor, I think that's okay. We just don't want code to be orphaned. We could use the xerces-j-user list to gauge the interest in proposed sub-projects. But I would have the final vote happen on xerces-j-dev.
2. Sub-project repositories:
a) Have separate repositories.
b) Add sub-projects under "xml-xerces/java", i.e.
"xml-xerces/java/neko", "xml-xerces/java/relaxng". I have a slight preference for this approach.
2b. But I wouldn't put each sub-project into its own directory directly from xml-xerces/java/. Over time, that will get very cluttered. I would suggest a top level dir for the sub-projects. Any suggestions?
3. Do we want to create only one sub-project, i.e. "toolbox"?
If we took this approach, we might as well just put the code in the main src/ dir and have different build scripts.
4. Sub-projects should have its own build file, documentation and jar
files, i.e. xerces-neko.jar.
Agreed, except for the Jar file name example. I'd prefer to not load up two codenames into a single filename -- very confusing. The name should indicate the function (e.g. xercesHtml.jar).
5. Exposing sub projects:
a) sub-projects could be linked directly from the xml.apache.org web
site b) sub-projects are linked from the Xerces web site.
5b.
6. Mailing lists: a) Create a mailing list for developers/users of the sub-project. b) Create one mailing list for all sub-projects. c) Don't create any mailing lists -- use xerces-j-dev/user for discussions.
6c.
7. Sub-projects should have its own releases (which don't necessarily match Xerces ones).
Agreed. But they will need to be documented as to which Xerces release they depend on much like the way Xalan depends on a specific release. Trying to make sure that all sub-projects are up-to-speed before each Xerces release would be difficult.
8. We should consider separate HTML/WML DOM components from the main Xerces projects.
Yes. When we add in NekoHTML, the HTML DOM could be combined with that. Speaking of which, do we have anyone that wants to update the HTML DOM implementation for XHTML? And while I'm thinking about it... We should do some much needed performance work on the HTML DOM implementation. I've heard from users of NekoHTML that the HTML DOM impl consumes a lot of the overall cycles. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
