You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by ne...@ca.ibm.com on 2001/11/22 18:44:21 UTC
[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
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Parsing DTD
Posted by Adam Najmanowicz <ad...@stardock.com>.
I need to parse the DTD in search for the defined elements and entities
is there any nice and clean way to do it?
Thanks for your time,
Adam Najmanowicz
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: [xerces2] info about some packaging changes
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 12:44 PM -0500 11/22/01, neilg@ca.ibm.com wrote:
>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.
>
Is this actually compatible with the DOM specs? If we're just talking
about the implementation classes then this isn't a problem; but if
you really do mean the interfaces then this is simply not a proper
implementation of DOM Level 3. I do not think we should break
compatibility with the DOOM3 spec, which specifies
"package org.w3c.dom" for all these interfaces just to meld well with
the proprietary technology of one company (Sun).
If this is really a problem, then the packages need to be changed in
the DOM spec now while it's in working draft status, rather than in
Xerces.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [xerces2] info about some packaging changes
Posted by Edwin Goei <ed...@sun.com>.
neilg@ca.ibm.com wrote:
>
> [snip]
>
> 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
^^^^^^^
Probably mean "org.w3c.dom" package here.
> a very big problem--it will require the modification of some
> import statements and variable declarations, but that should be
> it.
>
> [snip]
>
> 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!
Sorry, I was out b/c of Thanksgiving so only am now reading your email.
I've got a couple comments:
1) It looks like the META-INF/ directory got placed under the API jar
file and not the implementation jar file. The JAXP javax.xml.parsers.*
resource files are supposed to go in the implementation jar file. This
allows one to take the implementation jar file and put it on the
classpath of JDK 1.4, for example to use Xerces2 as the implementation.
BTW, there is still an unresolved issue using split jar files when
running as an applet on native VMs such as Netscape 4.7. For some
reason, code in one jarfile cannot read a resource in another jar file.
2) Are the mixed case jar file names going to cause problems on some
platforms like DOS?
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [xerces2] info about some packaging changes
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 12:44 PM -0500 11/22/01, neilg@ca.ibm.com wrote:
>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.
>
Is this actually compatible with the DOM specs? If we're just talking
about the implementation classes then this isn't a problem; but if
you really do mean the interfaces then this is simply not a proper
implementation of DOM Level 3. I do not think we should break
compatibility with the DOOM3 spec, which specifies
"package org.w3c.dom" for all these interfaces just to meld well with
the proprietary technology of one company (Sun).
If this is really a problem, then the packages need to be changed in
the DOM spec now while it's in working draft status, rather than in
Xerces.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org