Stefano Mazzocchi wrote: > > xml-xerces/java/neko > > Makes sense to me.
I would suggest using "xml-xerces/java/html" instead because "CyberNeko" is my personal domain and doesn't need to be used within Apache once it becomes a Xerces2 sub-project. I would retain the name if it was hosted and developed elsewhere, though. > That's what I was proposing earlier. As I told Andy, you might want to > take a look at Avalon and Turbine under jakarta to see how they handle > their subprojects. I've been incredibly busy these days but this is definitely on my list of things to do. > xerces-core.jar -> the XNI interfaces and internal machineries If this were to only contain the XNI interfaces, then I would call it "xerces-xni.jar". However, "*-core" is just fine if this Jar contains other things, such as the "internal machinery" you mentioned. (BTW, what qualifies as internal machinery?) > xerces-sax.jar -> the XML sax parser > xerces-dom.jar -> the XML DOM provider No problem here. > xerces-dtd.jar -> the DTD validator > xerces-schema.jar -> the XMLSchema validator Even this is possible. > xerces-neko.jar -> the HTML parser Depending on where it lives, I would suggest "xerces-html.jar" instead. > xerces-html-dom.jar -> the HTML DOM provider > xerces-wml-dom.jar -> the WML DOM provider Yep. The only issue we need to address is how the user selects the parser configuration that uses their set of features. > and no compression added to the jars to speedup classloading > (compression can be performed over the wire if required) We were thinking about compressing the jar files for the next minor release to see how the world reacts. So far, you're the only person with a counter argument for why we shouldn't compress the jar files. Which is faster: downloading a compressed jar + decompressing it OR downloading an uncompressed jar? If the user downloads the parser from the Net, I would think that uncompressing it locally is faster than waiting for that many more bytes to transfer. If the parser is used in a server environment, then this would be loaded at startup (or first use) and so you only pay the cost once. The only people adversely affected are those that bring up separate JVMs and need to re-load the parser jars every time. Therefore, I favor the first option. But of course the needs of the general community wins. So I'm hoping to hear from more people that would be affected by this change. So far, I've heard mostly from people requesting that we compress the jar files. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
