Re: [xerces2] info about some packaging changes

[Hasan Al-Sheboul <hs...@cs.nmsu.edu>]

Hi,

    So, where are the class implementation (similar to the ones that can be
found with XML4J) can be found (or how to build) into Xerces 2?

Thanks for the help.

neilg@ca.ibm.com wrote:

> Hello,
>
> We considered this approach actually.  At least these two things scared us
> off:  First, this might be a little interesting with regard to building and
> testing.  The big one though is that we weren't convinced that we could
> guarantee that our DOM implementation wouldn't end up having to use some
> DOM level 3 methods or interfaces.  If it did need to do so this method
> wouldn't work, because we wouldn't be able to guarantee at runtime that all
> the classes/methods we were expecting would exist.
>
> This is analogous to the problem with the idea of a dom1.jar:  Since DOM
> level 2 adds methods to DOM 1 interfaces (and so does DOM 3), and
> internally we rely on DOM 2 stuff in places, then supporting exactly DOM 1
> can't work.
>
> It's not a simple issue though; doing DOM l3 is somewhat painful for us too
> because of all the casting that needs to be done.  But at least this makes
> very clear to everybody what's experimental and what's carved in stone.
>
> Cheers,
> Neil
> Neil Graham
> XML Parser Development
> IBM Toronto Lab
> Phone:  905-413-3519, T/L 969-3519
> E-mail:  neilg@ca.ibm.com
>
> rpcee <rp...@operamail.com> on 11/23/2001 07:05:36 AM
>
> Please respond to xerces-j-user@xml.apache.org
>
> To:   xerces-j-user@xml.apache.org
> cc:
> Subject:  RE: [xerces2] info about some packaging changes
>
> don't fully grasp the issues, but would it be possible to just use ant
> targets
> to build a dom3 or dom2 version of xerces, with the correct packages? ie
> the
> source could be in a different place but the classes in the right place, no
>
> odd casting reqd etc.
>
> >===== Original Message From xerces-j-user@xml.apache.org =====
> >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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org


---------------------------------------------------------------------
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

[Andy Clark <an...@apache.org>]

Hasan Al-Sheboul wrote:
>     So, where are the class implementation (similar to the ones that can be
> found with XML4J) can be found (or how to build) into Xerces 2?

There are three downloadable packages. Check the following page
for info:  http://xml.apache.org/xerces2-j/install.html

-- 
Andy Clark * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org