xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ne...@ca.ibm.com
Subject [xerces2] info about some packaging changes
Date Thu, 22 Nov 2001 17:45:57 GMT
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:  neilg@ca.ibm.com



---------------------- Forwarded by Neil Graham/Toronto/IBM on 11/22/2001
12:44 PM ---------------------------

Neil Graham
11/22/2001 12:44 PM

To:   xerces-j-dev@xml.apache.org, xerces-j-user@xml.apache.org
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:  neilg@ca.ibm.com




---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message