Hi folks, This is pretty Xerces-specific. Nonetheless, I thought it worth posting here in case anyone has some feedback, and as a general heads-up regarding how xerces2 looks like being packaged in the future.
Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] ---------------------- Forwarded by Neil Graham/Toronto/IBM on 11/22/2001 12:44 PM --------------------------- Neil Graham 11/22/2001 12:44 PM To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: From: Neil Graham/Toronto/IBM@IBMCA Subject: [xerces2] info about some packaging changes Hi folks, I'd like to get your feedback on a couple of relatively minor changes some of the committers think need to be made (indeed, some of them have been already checked in :-)) and give everyone some background as to why they appear to be necessary. Naturally, this pertains to Xerces2. As people who habitually follow CVS commits will know, we've put all the new DOM level 3 interfaces in a new package--not in the org.w3c.dom hierarchy. The parts of DOM level 3 that were formerly included in the org.w3c.dom interfaces have been taken out, and we plan to create new interfaces in the new, DOM level 3-specific package (org.apache.xerces.dom3) that will extend the DOM level 2 interfaces by adding the appropriate methods. We're tentatively planning to call these interfaces things like Element3, Document3, etc., to preserve an obvious link between the new interfaces and the ones they extend, but to avoid forcing users to use fully-qualified package names whenever they need to cast to these interfaces. We've also created two packages under org.apache.xerces.dom3, to contain the DOM level three Load and Save and Abstract Schema specifications. Why all this rigmarole? The main reason is that some products, which want to become certified by Sun as being either J2EE-compliant or J2SE-compliant, want to use Xerces2 as their XML parser. (No doubt somebody will ask for specific names; IBM Websphere and IBM's JDK are the specific products we're dealing with here.) We're pretty honoured by this, but it does mean that we need to support *exactly* DOM level 2--because this is what Sun requires of parsers included in products that obtain these certifications. A side-benefit of this reorganization is that it makes very clear to users what parts of the DOM are still considered experimental, so that they know they're relying on methods or interfaces that might theoretically change or go away. However, from the standpoint of a user wishing to use DOM level 3 interfaces or methods this does have two downsides. First, it means that a lot of casting will need to be done: DOM's methods return DOM level 2 objects; e.g., Node.getOwnerDocument() returns an org.w3c.dom.Document, so if you want the DOM level three version, you'll have to explicitly cast this to org.apache.xerces.dom3.Document3. Secondly, once DOM level 3 becomes a standard and is incorporated into Sun's certification suites etc., applications using our repackaged DOM level 3 support will need to be modified so that they use the org.apache.dom packages. This wouldn't appear to be a very big problem--it will require the modification of some import statements and variable declarations, but that should be it. since reorganizing the DOM seems to be needed anyway, we thought it might also be a good time to follow Xalan's lead and split the API's we support and the implementation of those API's into separate jar files. We're planning to keep the API jar as close to the xml-apis.jar that xml-commons produces as possible, but obviously we won't be shipping the javax.xml.transform packages, since we don't implement these interfaces. We also plan to keep our API's in our own CVS repository, periodically checking to make sure they're in sync with xml-commons. We don't want to use xml-commons so that we can move quickly on API updates--such as when DOM level 3 becomes a full-fledged recommendation. The advantage for users of this API split is that it could save them some space: If you want to use Xerces and Xalan together, then you only need to include one API jar file on your classpath to make everything work. This means your xerces jarfile will be about 7% smaller than it would be if it contained API's as well as implementations. For those who like the current system, we're going to have an ant task in our build file that permits the generation of the current jarfile--that is, a jarfile containing API's + implementation. We thought that binary distributions would only include the new, split-up jarfiles. For those concerned about names: we thought we'd call the new implementation-specific jarfile xercesImpl.jar, so as to distinguish it from the xerces.jar that contains everything. The API file we thought could be called xmlParserAPIs.jar, since it contains only API's related to XML parsing. We'd definitely love feedback on these proposals. I've got the necessary buildfile changes on my local machine, and I'd like to commit them quickly; so if anyone has any really serious reservations about the API reorganization, please speak up now! Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
