Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Old Xerces Version
Old Xerces Version [message #21316] Wed, 07 May 2003 09:40 Go to next message
Eclipse UserFriend
Originally posted by: paechoi.earthlink.net

I have noticed that we have some confusions/inconvenience
or can cause the confusion/inconvenience as follows:

1.Eclipse uses the Xerces, but uses own version number. Would
not it be better if we all use the same Xerces version?
2. Some of us use the XSD as a standalone, not with Eclipse Editor.
So for those of who use the XSD as a standlone package, the
restriction of (old) Xerces version is not relevant.
3. I am not sure for the rest of the XSD users, but I need to use
the latest stable release of Xerces. And the XSD is an attractive
package to use, but requres to use an old Xerces pacakge. This
results to use two different Xerces packages. Not so good!
4. I understand that sync-ing with other team project is an important,
but is XSD will always stuck with *old* Xerces if the usage of
Xerces in the Eclipse Editor remain as is? Don't we need to have
at least a plan for it if so.

I am not sure how others think about this, but I's certainly like
to hear about this and resolve this for better. Thank you.

Regards,


Pae
Re: Old Xerces Version [message #21563 is a reply to message #21316] Wed, 07 May 2003 11:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Pae,

Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't move
along more quickly. But I have no control or influence over that. Part
of the problem here too is changes in Xerces that make it incompatible
from one version to the next. (I.e., the current Eclipse Xerces version
doesn't support a way to access the XML encoding without major hacking.)
But I have no control or influence over Xerces either.

The concerns you express also affect IBM products like WSAD, which use
Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No matter
what happens, a version of Xerces must be chosen, XSD must be made to work
with that version, and anyone downstream (including WSAD) is bound by that
choice. If a newer version of Xerces comes along and XSD works with that
too, that's wonderful; but if it doesn't work with that version, then more
work needs to be done and a large number of folks all need to move to a
new version at once...

I don't see a way for me to fix this, however much I may want to...


Pae Choi wrote:

> I have noticed that we have some confusions/inconvenience
> or can cause the confusion/inconvenience as follows:
>
> 1.Eclipse uses the Xerces, but uses own version number. Would
> not it be better if we all use the same Xerces version?
> 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> So for those of who use the XSD as a standlone package, the
> restriction of (old) Xerces version is not relevant.
> 3. I am not sure for the rest of the XSD users, but I need to use
> the latest stable release of Xerces. And the XSD is an attractive
> package to use, but requres to use an old Xerces pacakge. This
> results to use two different Xerces packages. Not so good!
> 4. I understand that sync-ing with other team project is an important,
> but is XSD will always stuck with *old* Xerces if the usage of
> Xerces in the Eclipse Editor remain as is? Don't we need to have
> at least a plan for it if so.
>
> I am not sure how others think about this, but I's certainly like
> to hear about this and resolve this for better. Thank you.
>
> Regards,
>
> Pae
Re: Old Xerces Version [message #21653 is a reply to message #21563] Sat, 10 May 2003 18:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: paechoi.earthlink.net

Ed,

I've been used the Xerces v2.2.1 for the projects I am involving at
present. And I was going to move out to the latest release of Xerces
such as v2.4.0 when the time comes.

Since I am pretty much enjoying the Eclipse/XSD and planning to adop
it, I am seeing myself going back to Xerces v2.0.2.

Withdrawing from v2.4.0 and moving along the line of regression curve,
I am concerned for the possible obstacles that may cause the project
downtime. And the resression is not part of my nature, I am more to
the progression same as many other folks in the open-source community.

I am only using and intend to use(at least, for now) the XSD as standlone
package. I wonder if the Eclipse/XSD is standalone package, would it
make possible and simple to grab and use the later Xerces package? If so,
would you think that making two different distributions -- one for as is
now and another for standalone package that uses the later Xerces
package.

I would more than happy to hear about any other workarounds and/or
comments for integrating the Eclipse/XSD with later Xerces package if
you and/or other folks have. Thank you.

Regards,


Pae



"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3EB8EB24.99F904DD@ca.ibm.com...
> Pae,
>
> Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't move
> along more quickly. But I have no control or influence over that. Part
> of the problem here too is changes in Xerces that make it incompatible
> from one version to the next. (I.e., the current Eclipse Xerces version
> doesn't support a way to access the XML encoding without major hacking.)
> But I have no control or influence over Xerces either.
>
> The concerns you express also affect IBM products like WSAD, which use
> Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No matter
> what happens, a version of Xerces must be chosen, XSD must be made to work
> with that version, and anyone downstream (including WSAD) is bound by that
> choice. If a newer version of Xerces comes along and XSD works with that
> too, that's wonderful; but if it doesn't work with that version, then more
> work needs to be done and a large number of folks all need to move to a
> new version at once...
>
> I don't see a way for me to fix this, however much I may want to...
>
>
> Pae Choi wrote:
>
> > I have noticed that we have some confusions/inconvenience
> > or can cause the confusion/inconvenience as follows:
> >
> > 1.Eclipse uses the Xerces, but uses own version number. Would
> > not it be better if we all use the same Xerces version?
> > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > So for those of who use the XSD as a standlone package, the
> > restriction of (old) Xerces version is not relevant.
> > 3. I am not sure for the rest of the XSD users, but I need to use
> > the latest stable release of Xerces. And the XSD is an attractive
> > package to use, but requres to use an old Xerces pacakge. This
> > results to use two different Xerces packages. Not so good!
> > 4. I understand that sync-ing with other team project is an important,
> > but is XSD will always stuck with *old* Xerces if the usage of
> > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > at least a plan for it if so.
> >
> > I am not sure how others think about this, but I's certainly like
> > to hear about this and resolve this for better. Thank you.
> >
> > Regards,
> >
> > Pae
>
Re: Old Xerces Version [message #21743 is a reply to message #21563] Mon, 12 May 2003 06:24 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3EB8EB24.99F904DD@ca.ibm.com...
> I don't see a way for me to fix this, however much I may want to...

Well, crap. I'm not blaming the messenger, but it is pretty ridiculous that
this is being mishandled and no one on the planet is responsible.

The version of xerces that ships with eclipse 2.1 (and 2.0) contains a bug
that has been fixed in newer versions of both xerces and xml4j. The bug
makes xerces not work with entityResolvers when schemas are parsed. (The
same bug affected all documents in the recent past. It stemmed from the same
misunderstanding of how entityResolvers work.)

There seems to be no place to file a bug report about problems like this.
Eclipse routinely ignores or closes them. Xml4j doesn't have the bug any
more.

If you (within IBM from whence these versions flow) feel helpless, imagine
how it is for us. :-(

Bob
Re: Old Xerces Version [message #21834 is a reply to message #21653] Mon, 12 May 2003 12:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Pae,

I tried getting the latest Xerces 2.4.0 to see what problems I have.
Unfortunately there are many. XSD uses some of the Xerces datatypes for
representing date values as well as things like HexBinary and Base64Binary. All
of these things look like they've changed in incompatible ways that will require
changes in XSD in order to for me to step up to the latest Xerces.

Maintaining two versions of XSD in order to target two different versions of
Xerces is not something that I will be able to sustain with my very limited
available time.


Pae Choi wrote:

> Ed,
>
> I've been used the Xerces v2.2.1 for the projects I am involving at
> present. And I was going to move out to the latest release of Xerces
> such as v2.4.0 when the time comes.
>
> Since I am pretty much enjoying the Eclipse/XSD and planning to adop
> it, I am seeing myself going back to Xerces v2.0.2.
>
> Withdrawing from v2.4.0 and moving along the line of regression curve,
> I am concerned for the possible obstacles that may cause the project
> downtime. And the resression is not part of my nature, I am more to
> the progression same as many other folks in the open-source community.
>
> I am only using and intend to use(at least, for now) the XSD as standlone
> package. I wonder if the Eclipse/XSD is standalone package, would it
> make possible and simple to grab and use the later Xerces package? If so,
> would you think that making two different distributions -- one for as is
> now and another for standalone package that uses the later Xerces
> package.
>
> I would more than happy to hear about any other workarounds and/or
> comments for integrating the Eclipse/XSD with later Xerces package if
> you and/or other folks have. Thank you.
>
> Regards,
>
> Pae
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3EB8EB24.99F904DD@ca.ibm.com...
> > Pae,
> >
> > Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't move
> > along more quickly. But I have no control or influence over that. Part
> > of the problem here too is changes in Xerces that make it incompatible
> > from one version to the next. (I.e., the current Eclipse Xerces version
> > doesn't support a way to access the XML encoding without major hacking.)
> > But I have no control or influence over Xerces either.
> >
> > The concerns you express also affect IBM products like WSAD, which use
> > Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No matter
> > what happens, a version of Xerces must be chosen, XSD must be made to work
> > with that version, and anyone downstream (including WSAD) is bound by that
> > choice. If a newer version of Xerces comes along and XSD works with that
> > too, that's wonderful; but if it doesn't work with that version, then more
> > work needs to be done and a large number of folks all need to move to a
> > new version at once...
> >
> > I don't see a way for me to fix this, however much I may want to...
> >
> >
> > Pae Choi wrote:
> >
> > > I have noticed that we have some confusions/inconvenience
> > > or can cause the confusion/inconvenience as follows:
> > >
> > > 1.Eclipse uses the Xerces, but uses own version number. Would
> > > not it be better if we all use the same Xerces version?
> > > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > > So for those of who use the XSD as a standlone package, the
> > > restriction of (old) Xerces version is not relevant.
> > > 3. I am not sure for the rest of the XSD users, but I need to use
> > > the latest stable release of Xerces. And the XSD is an attractive
> > > package to use, but requres to use an old Xerces pacakge. This
> > > results to use two different Xerces packages. Not so good!
> > > 4. I understand that sync-ing with other team project is an important,
> > > but is XSD will always stuck with *old* Xerces if the usage of
> > > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > > at least a plan for it if so.
> > >
> > > I am not sure how others think about this, but I's certainly like
> > > to hear about this and resolve this for better. Thank you.
> > >
> > > Regards,
> > >
> > > Pae
> >
Re: Old Xerces Version [message #21880 is a reply to message #21743] Mon, 12 May 2003 13:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Bob,

I can imagine all too well. Sorry...

Bob Foster wrote:

> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3EB8EB24.99F904DD@ca.ibm.com...
> > I don't see a way for me to fix this, however much I may want to...
>
> Well, crap. I'm not blaming the messenger, but it is pretty ridiculous that
> this is being mishandled and no one on the planet is responsible.
>
> The version of xerces that ships with eclipse 2.1 (and 2.0) contains a bug
> that has been fixed in newer versions of both xerces and xml4j. The bug
> makes xerces not work with entityResolvers when schemas are parsed. (The
> same bug affected all documents in the recent past. It stemmed from the same
> misunderstanding of how entityResolvers work.)
>
> There seems to be no place to file a bug report about problems like this.
> Eclipse routinely ignores or closes them. Xml4j doesn't have the bug any
> more.
>
> If you (within IBM from whence these versions flow) feel helpless, imagine
> how it is for us. :-(
>
> Bob
Re: Old Xerces Version [message #22056 is a reply to message #21834] Tue, 13 May 2003 00:52 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: paechoi.earthlink.net

Ed,

Thank you for your extra efforts as well as taking time in regarding on
this issue.

I can sense the chanllenges for migrating Eclipse/XSD with later Xerces
and understand that it is not an overnight task. I also understand you as
well are one of us who think and desire that we should take some action
for this issue. I am glad that at least we are in the same page.

I am not trying to be selfish here, but my main and a sole(for now) purpose
to *use* the Eclipse/XSD package is for XML Schema validation. And I am
getting feelings and feedbacks that retreating back to Xerces v2.0.2 is
getting out of option at my case.

I am not sure if your initial investigation was sufficient to provide me the
answers for the inquires as follows:

1. Is it possible and feasible to liberate from the Xerces v2.0.2?
2. If so, what kind of time frame you are looking at it in a rough
estimation?
3. This is specifically for my case. How difficult would it be if I extract
the mechanisms just for "Validation" out of it?

Regards,


Pae





"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3EBF99F1.FCD1CC88@ca.ibm.com...
> Pae,
>
> I tried getting the latest Xerces 2.4.0 to see what problems I have.
> Unfortunately there are many. XSD uses some of the Xerces datatypes for
> representing date values as well as things like HexBinary and
Base64Binary. All
> of these things look like they've changed in incompatible ways that will
require
> changes in XSD in order to for me to step up to the latest Xerces.
>
> Maintaining two versions of XSD in order to target two different versions
of
> Xerces is not something that I will be able to sustain with my very
limited
> available time.
>
>
> Pae Choi wrote:
>
> > Ed,
> >
> > I've been used the Xerces v2.2.1 for the projects I am involving at
> > present. And I was going to move out to the latest release of Xerces
> > such as v2.4.0 when the time comes.
> >
> > Since I am pretty much enjoying the Eclipse/XSD and planning to adop
> > it, I am seeing myself going back to Xerces v2.0.2.
> >
> > Withdrawing from v2.4.0 and moving along the line of regression curve,
> > I am concerned for the possible obstacles that may cause the project
> > downtime. And the resression is not part of my nature, I am more to
> > the progression same as many other folks in the open-source community.
> >
> > I am only using and intend to use(at least, for now) the XSD as
standlone
> > package. I wonder if the Eclipse/XSD is standalone package, would it
> > make possible and simple to grab and use the later Xerces package? If
so,
> > would you think that making two different distributions -- one for as is
> > now and another for standalone package that uses the later Xerces
> > package.
> >
> > I would more than happy to hear about any other workarounds and/or
> > comments for integrating the Eclipse/XSD with later Xerces package if
> > you and/or other folks have. Thank you.
> >
> > Regards,
> >
> > Pae
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3EB8EB24.99F904DD@ca.ibm.com...
> > > Pae,
> > >
> > > Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't
move
> > > along more quickly. But I have no control or influence over that.
Part
> > > of the problem here too is changes in Xerces that make it incompatible
> > > from one version to the next. (I.e., the current Eclipse Xerces
version
> > > doesn't support a way to access the XML encoding without major
hacking.)
> > > But I have no control or influence over Xerces either.
> > >
> > > The concerns you express also affect IBM products like WSAD, which use
> > > Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No
matter
> > > what happens, a version of Xerces must be chosen, XSD must be made to
work
> > > with that version, and anyone downstream (including WSAD) is bound by
that
> > > choice. If a newer version of Xerces comes along and XSD works with
that
> > > too, that's wonderful; but if it doesn't work with that version, then
more
> > > work needs to be done and a large number of folks all need to move to
a
> > > new version at once...
> > >
> > > I don't see a way for me to fix this, however much I may want to...
> > >
> > >
> > > Pae Choi wrote:
> > >
> > > > I have noticed that we have some confusions/inconvenience
> > > > or can cause the confusion/inconvenience as follows:
> > > >
> > > > 1.Eclipse uses the Xerces, but uses own version number. Would
> > > > not it be better if we all use the same Xerces version?
> > > > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > > > So for those of who use the XSD as a standlone package, the
> > > > restriction of (old) Xerces version is not relevant.
> > > > 3. I am not sure for the rest of the XSD users, but I need to use
> > > > the latest stable release of Xerces. And the XSD is an
attractive
> > > > package to use, but requres to use an old Xerces pacakge. This
> > > > results to use two different Xerces packages. Not so good!
> > > > 4. I understand that sync-ing with other team project is an
important,
> > > > but is XSD will always stuck with *old* Xerces if the usage of
> > > > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > > > at least a plan for it if so.
> > > >
> > > > I am not sure how others think about this, but I's certainly like
> > > > to hear about this and resolve this for better. Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Pae
> > >
>
Re: Old Xerces Version [message #22197 is a reply to message #22056] Tue, 13 May 2003 09:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Pae,

Moving to a new version of Xerces will involve some changes in the XSDParser and
XSDResourceImpl, which do the parsing, as well as some changes in
org.eclipse.xsd.impl.type, which use Xerces schema types to implement XML Schema
values. The changes are relatively straight forward and I doubt would take more
than a day of effort. I'm not sure what you mean by separating "Validation"
out, but I doubt there's anything easily separable from the rest of the code.

A truly persistent person would be able to derive from XSDResourceImpl and
override doLoad to use a copied and changed version of XSDParser that works with
a different version of Xerces. They would also be able to create alternative
implementations of the types in org.eclipse.xsd.impl.type that work with a
different version of Xerces; these alternatives could be registered in the
XSDTypeRegister in that package...


Pae Choi wrote:

> Ed,
>
> Thank you for your extra efforts as well as taking time in regarding on
> this issue.
>
> I can sense the chanllenges for migrating Eclipse/XSD with later Xerces
> and understand that it is not an overnight task. I also understand you as
> well are one of us who think and desire that we should take some action
> for this issue. I am glad that at least we are in the same page.
>
> I am not trying to be selfish here, but my main and a sole(for now) purpose
> to *use* the Eclipse/XSD package is for XML Schema validation. And I am
> getting feelings and feedbacks that retreating back to Xerces v2.0.2 is
> getting out of option at my case.
>
> I am not sure if your initial investigation was sufficient to provide me the
> answers for the inquires as follows:
>
> 1. Is it possible and feasible to liberate from the Xerces v2.0.2?
> 2. If so, what kind of time frame you are looking at it in a rough
> estimation?
> 3. This is specifically for my case. How difficult would it be if I extract
> the mechanisms just for "Validation" out of it?
>
> Regards,
>
> Pae
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3EBF99F1.FCD1CC88@ca.ibm.com...
> > Pae,
> >
> > I tried getting the latest Xerces 2.4.0 to see what problems I have.
> > Unfortunately there are many. XSD uses some of the Xerces datatypes for
> > representing date values as well as things like HexBinary and
> Base64Binary. All
> > of these things look like they've changed in incompatible ways that will
> require
> > changes in XSD in order to for me to step up to the latest Xerces.
> >
> > Maintaining two versions of XSD in order to target two different versions
> of
> > Xerces is not something that I will be able to sustain with my very
> limited
> > available time.
> >
> >
> > Pae Choi wrote:
> >
> > > Ed,
> > >
> > > I've been used the Xerces v2.2.1 for the projects I am involving at
> > > present. And I was going to move out to the latest release of Xerces
> > > such as v2.4.0 when the time comes.
> > >
> > > Since I am pretty much enjoying the Eclipse/XSD and planning to adop
> > > it, I am seeing myself going back to Xerces v2.0.2.
> > >
> > > Withdrawing from v2.4.0 and moving along the line of regression curve,
> > > I am concerned for the possible obstacles that may cause the project
> > > downtime. And the resression is not part of my nature, I am more to
> > > the progression same as many other folks in the open-source community.
> > >
> > > I am only using and intend to use(at least, for now) the XSD as
> standlone
> > > package. I wonder if the Eclipse/XSD is standalone package, would it
> > > make possible and simple to grab and use the later Xerces package? If
> so,
> > > would you think that making two different distributions -- one for as is
> > > now and another for standalone package that uses the later Xerces
> > > package.
> > >
> > > I would more than happy to hear about any other workarounds and/or
> > > comments for integrating the Eclipse/XSD with later Xerces package if
> > > you and/or other folks have. Thank you.
> > >
> > > Regards,
> > >
> > > Pae
> > >
> > > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > > news:3EB8EB24.99F904DD@ca.ibm.com...
> > > > Pae,
> > > >
> > > > Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't
> move
> > > > along more quickly. But I have no control or influence over that.
> Part
> > > > of the problem here too is changes in Xerces that make it incompatible
> > > > from one version to the next. (I.e., the current Eclipse Xerces
> version
> > > > doesn't support a way to access the XML encoding without major
> hacking.)
> > > > But I have no control or influence over Xerces either.
> > > >
> > > > The concerns you express also affect IBM products like WSAD, which use
> > > > Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No
> matter
> > > > what happens, a version of Xerces must be chosen, XSD must be made to
> work
> > > > with that version, and anyone downstream (including WSAD) is bound by
> that
> > > > choice. If a newer version of Xerces comes along and XSD works with
> that
> > > > too, that's wonderful; but if it doesn't work with that version, then
> more
> > > > work needs to be done and a large number of folks all need to move to
> a
> > > > new version at once...
> > > >
> > > > I don't see a way for me to fix this, however much I may want to...
> > > >
> > > >
> > > > Pae Choi wrote:
> > > >
> > > > > I have noticed that we have some confusions/inconvenience
> > > > > or can cause the confusion/inconvenience as follows:
> > > > >
> > > > > 1.Eclipse uses the Xerces, but uses own version number. Would
> > > > > not it be better if we all use the same Xerces version?
> > > > > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > > > > So for those of who use the XSD as a standlone package, the
> > > > > restriction of (old) Xerces version is not relevant.
> > > > > 3. I am not sure for the rest of the XSD users, but I need to use
> > > > > the latest stable release of Xerces. And the XSD is an
> attractive
> > > > > package to use, but requres to use an old Xerces pacakge. This
> > > > > results to use two different Xerces packages. Not so good!
> > > > > 4. I understand that sync-ing with other team project is an
> important,
> > > > > but is XSD will always stuck with *old* Xerces if the usage of
> > > > > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > > > > at least a plan for it if so.
> > > > >
> > > > > I am not sure how others think about this, but I's certainly like
> > > > > to hear about this and resolve this for better. Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Pae
> > > >
> >
Re: Old Xerces Version [message #23717 is a reply to message #21316] Wed, 18 June 2003 00:04 Go to previous messageGo to next message
Mike Dickson is currently offline Mike DicksonFriend
Messages: 8
Registered: July 2009
Junior Member
Does eclipse have any notion of multiple versions of a package as plugins?
That is, could you package up the newer version of Xerces as a plugin with
different version info and make the XSD stuff dependant on it while core
eclipse continues to use the old version. This would of course require some
flexibility in classloading but it is possible and it would help obviate
problems like this where XSD is stuck and kept from moving ahead because of
an old version in eclipse.

Mike

"Pae Choi" <paechoi@earthlink.net> wrote in message
news:b9ak8q$oam$1@rogue.oti.com...
> I have noticed that we have some confusions/inconvenience
> or can cause the confusion/inconvenience as follows:
>
> 1.Eclipse uses the Xerces, but uses own version number. Would
> not it be better if we all use the same Xerces version?
> 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> So for those of who use the XSD as a standlone package, the
> restriction of (old) Xerces version is not relevant.
> 3. I am not sure for the rest of the XSD users, but I need to use
> the latest stable release of Xerces. And the XSD is an attractive
> package to use, but requres to use an old Xerces pacakge. This
> results to use two different Xerces packages. Not so good!
> 4. I understand that sync-ing with other team project is an important,
> but is XSD will always stuck with *old* Xerces if the usage of
> Xerces in the Eclipse Editor remain as is? Don't we need to have
> at least a plan for it if so.
>
> I am not sure how others think about this, but I's certainly like
> to hear about this and resolve this for better. Thank you.
>
> Regards,
>
>
> Pae
>
>
>
Re: Old Xerces Version [message #23802 is a reply to message #23717] Wed, 18 June 2003 10:49 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Michael,

It's possible, but it presents it's own problems since the DOM produced by XSD
might be used by some code that depends explicitly on a different version of
Xerces or the DOM from some other version of Xerces might be passed to XSD.
IBM's WSAD has been careful to avoid this type of problem, so I don't want to be
the one who reintroduces it. I don't think I could get the agreement, even if I
did try. I was only able to get an upgrade to Xerces 4.0.13 to happen, and that
turned out to be of little advantage...


Michael Dickson wrote:

> Does eclipse have any notion of multiple versions of a package as plugins?
> That is, could you package up the newer version of Xerces as a plugin with
> different version info and make the XSD stuff dependant on it while core
> eclipse continues to use the old version. This would of course require some
> flexibility in classloading but it is possible and it would help obviate
> problems like this where XSD is stuck and kept from moving ahead because of
> an old version in eclipse.
>
> Mike
>
> "Pae Choi" <paechoi@earthlink.net> wrote in message
> news:b9ak8q$oam$1@rogue.oti.com...
> > I have noticed that we have some confusions/inconvenience
> > or can cause the confusion/inconvenience as follows:
> >
> > 1.Eclipse uses the Xerces, but uses own version number. Would
> > not it be better if we all use the same Xerces version?
> > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > So for those of who use the XSD as a standlone package, the
> > restriction of (old) Xerces version is not relevant.
> > 3. I am not sure for the rest of the XSD users, but I need to use
> > the latest stable release of Xerces. And the XSD is an attractive
> > package to use, but requres to use an old Xerces pacakge. This
> > results to use two different Xerces packages. Not so good!
> > 4. I understand that sync-ing with other team project is an important,
> > but is XSD will always stuck with *old* Xerces if the usage of
> > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > at least a plan for it if so.
> >
> > I am not sure how others think about this, but I's certainly like
> > to hear about this and resolve this for better. Thank you.
> >
> > Regards,
> >
> >
> > Pae
> >
> >
> >
Re: Old Xerces Version [message #23845 is a reply to message #22197] Thu, 19 June 2003 16:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stefano.turri.it.ibm.com

Hi,

I'm trying to use XSD in a standalone project (not using Eclipse), and I'm
having some problems, since the this project uses Xerces 2.4.0.

The XML parsing seems Ok (I Havent't found any problem yet), and the
problems appear only when validating simple type values.

Following your suggestion I'm registering alternative type implementation
(based on Xerces 2.4.0) to replace the one in org.eclipse.xsd.impl.type
based on Xerces 2.0.x. This is solving the validation problem, and permits
the use of Xerces 2.4.0. Are there any other kind of side effects I shuld
be aware of in doing this?

Perhaps the type classes in org.eclipse.xsd.impl.type might be release in
a different separate jar, and XSD might be able to switch between 2.0.x
and 2.x.x only changing between different version of this support jar,
while keeping the core XSD in its own jar.

Regards,
Stefano Turri



Ed Merks wrote:

> A truly persistent person would be able to derive from XSDResourceImpl and
> override doLoad to use a copied and changed version of XSDParser that works
with
> a different version of Xerces. They would also be able to create alternative
> implementations of the types in org.eclipse.xsd.impl.type that work with a
> different version of Xerces; these alternatives could be registered in the
> XSDTypeRegister in that package...
Re: Old Xerces Version [message #23886 is a reply to message #23845] Thu, 19 June 2003 16:45 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Stefano,

I'm very glad (and impressed) that you found workarounds that help to get you
going! Although your suggestion for how to handle multiple version of Xerces is a
good one, we are too late in the 1.1.0 development cycle to make changes like this
(and my spare cycles to address this are nonexistent). We could also try to do
things via reflection so that one code base works against multiple versions of
Xerces, but again, I haven't had the time to follow up on that. I'm hopeful that
folks will bear with me and that this problem will be eliminated in Eclipse 3.0
when the Eclipse 2.1.1 work is complete...

Stefano Turri wrote:

> Hi,
>
> I'm trying to use XSD in a standalone project (not using Eclipse), and I'm
> having some problems, since the this project uses Xerces 2.4.0.
>
> The XML parsing seems Ok (I Havent't found any problem yet), and the
> problems appear only when validating simple type values.
>
> Following your suggestion I'm registering alternative type implementation
> (based on Xerces 2.4.0) to replace the one in org.eclipse.xsd.impl.type
> based on Xerces 2.0.x. This is solving the validation problem, and permits
> the use of Xerces 2.4.0. Are there any other kind of side effects I shuld
> be aware of in doing this?
>
> Perhaps the type classes in org.eclipse.xsd.impl.type might be release in
> a different separate jar, and XSD might be able to switch between 2.0.x
> and 2.x.x only changing between different version of this support jar,
> while keeping the core XSD in its own jar.
>
> Regards,
> Stefano Turri
>
> Ed Merks wrote:
>
> > A truly persistent person would be able to derive from XSDResourceImpl and
> > override doLoad to use a copied and changed version of XSDParser that works
> with
> > a different version of Xerces. They would also be able to create alternative
> > implementations of the types in org.eclipse.xsd.impl.type that work with a
> > different version of Xerces; these alternatives could be registered in the
> > XSDTypeRegister in that package...
Re: Old Xerces Version [message #570833 is a reply to message #21316] Wed, 07 May 2003 11:16 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31362
Registered: July 2009
Senior Member
Pae,

Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't move
along more quickly. But I have no control or influence over that. Part
of the problem here too is changes in Xerces that make it incompatible
from one version to the next. (I.e., the current Eclipse Xerces version
doesn't support a way to access the XML encoding without major hacking.)
But I have no control or influence over Xerces either.

The concerns you express also affect IBM products like WSAD, which use
Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No matter
what happens, a version of Xerces must be chosen, XSD must be made to work
with that version, and anyone downstream (including WSAD) is bound by that
choice. If a newer version of Xerces comes along and XSD works with that
too, that's wonderful; but if it doesn't work with that version, then more
work needs to be done and a large number of folks all need to move to a
new version at once...

I don't see a way for me to fix this, however much I may want to...


Pae Choi wrote:

> I have noticed that we have some confusions/inconvenience
> or can cause the confusion/inconvenience as follows:
>
> 1.Eclipse uses the Xerces, but uses own version number. Would
> not it be better if we all use the same Xerces version?
> 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> So for those of who use the XSD as a standlone package, the
> restriction of (old) Xerces version is not relevant.
> 3. I am not sure for the rest of the XSD users, but I need to use
> the latest stable release of Xerces. And the XSD is an attractive
> package to use, but requres to use an old Xerces pacakge. This
> results to use two different Xerces packages. Not so good!
> 4. I understand that sync-ing with other team project is an important,
> but is XSD will always stuck with *old* Xerces if the usage of
> Xerces in the Eclipse Editor remain as is? Don't we need to have
> at least a plan for it if so.
>
> I am not sure how others think about this, but I's certainly like
> to hear about this and resolve this for better. Thank you.
>
> Regards,
>
> Pae


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Old Xerces Version [message #570904 is a reply to message #21563] Sat, 10 May 2003 18:05 Go to previous message
Eclipse UserFriend
Originally posted by: paechoi.earthlink.net

Ed,

I've been used the Xerces v2.2.1 for the projects I am involving at
present. And I was going to move out to the latest release of Xerces
such as v2.4.0 when the time comes.

Since I am pretty much enjoying the Eclipse/XSD and planning to adop
it, I am seeing myself going back to Xerces v2.0.2.

Withdrawing from v2.4.0 and moving along the line of regression curve,
I am concerned for the possible obstacles that may cause the project
downtime. And the resression is not part of my nature, I am more to
the progression same as many other folks in the open-source community.

I am only using and intend to use(at least, for now) the XSD as standlone
package. I wonder if the Eclipse/XSD is standalone package, would it
make possible and simple to grab and use the later Xerces package? If so,
would you think that making two different distributions -- one for as is
now and another for standalone package that uses the later Xerces
package.

I would more than happy to hear about any other workarounds and/or
comments for integrating the Eclipse/XSD with later Xerces package if
you and/or other folks have. Thank you.

Regards,


Pae



"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3EB8EB24.99F904DD@ca.ibm.com...
> Pae,
>
> Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't move
> along more quickly. But I have no control or influence over that. Part
> of the problem here too is changes in Xerces that make it incompatible
> from one version to the next. (I.e., the current Eclipse Xerces version
> doesn't support a way to access the XML encoding without major hacking.)
> But I have no control or influence over Xerces either.
>
> The concerns you express also affect IBM products like WSAD, which use
> Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No matter
> what happens, a version of Xerces must be chosen, XSD must be made to work
> with that version, and anyone downstream (including WSAD) is bound by that
> choice. If a newer version of Xerces comes along and XSD works with that
> too, that's wonderful; but if it doesn't work with that version, then more
> work needs to be done and a large number of folks all need to move to a
> new version at once...
>
> I don't see a way for me to fix this, however much I may want to...
>
>
> Pae Choi wrote:
>
> > I have noticed that we have some confusions/inconvenience
> > or can cause the confusion/inconvenience as follows:
> >
> > 1.Eclipse uses the Xerces, but uses own version number. Would
> > not it be better if we all use the same Xerces version?
> > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > So for those of who use the XSD as a standlone package, the
> > restriction of (old) Xerces version is not relevant.
> > 3. I am not sure for the rest of the XSD users, but I need to use
> > the latest stable release of Xerces. And the XSD is an attractive
> > package to use, but requres to use an old Xerces pacakge. This
> > results to use two different Xerces packages. Not so good!
> > 4. I understand that sync-ing with other team project is an important,
> > but is XSD will always stuck with *old* Xerces if the usage of
> > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > at least a plan for it if so.
> >
> > I am not sure how others think about this, but I's certainly like
> > to hear about this and resolve this for better. Thank you.
> >
> > Regards,
> >
> > Pae
>
Re: Old Xerces Version [message #571052 is a reply to message #21563] Mon, 12 May 2003 06:24 Go to previous message
Eclipse UserFriend
Originally posted by: bob.objfac.com

"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3EB8EB24.99F904DD@ca.ibm.com...
> I don't see a way for me to fix this, however much I may want to...

Well, crap. I'm not blaming the messenger, but it is pretty ridiculous that
this is being mishandled and no one on the planet is responsible.

The version of xerces that ships with eclipse 2.1 (and 2.0) contains a bug
that has been fixed in newer versions of both xerces and xml4j. The bug
makes xerces not work with entityResolvers when schemas are parsed. (The
same bug affected all documents in the recent past. It stemmed from the same
misunderstanding of how entityResolvers work.)

There seems to be no place to file a bug report about problems like this.
Eclipse routinely ignores or closes them. Xml4j doesn't have the bug any
more.

If you (within IBM from whence these versions flow) feel helpless, imagine
how it is for us. :-(

Bob
Re: Old Xerces Version [message #571150 is a reply to message #21653] Mon, 12 May 2003 12:56 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31362
Registered: July 2009
Senior Member
Pae,

I tried getting the latest Xerces 2.4.0 to see what problems I have.
Unfortunately there are many. XSD uses some of the Xerces datatypes for
representing date values as well as things like HexBinary and Base64Binary. All
of these things look like they've changed in incompatible ways that will require
changes in XSD in order to for me to step up to the latest Xerces.

Maintaining two versions of XSD in order to target two different versions of
Xerces is not something that I will be able to sustain with my very limited
available time.


Pae Choi wrote:

> Ed,
>
> I've been used the Xerces v2.2.1 for the projects I am involving at
> present. And I was going to move out to the latest release of Xerces
> such as v2.4.0 when the time comes.
>
> Since I am pretty much enjoying the Eclipse/XSD and planning to adop
> it, I am seeing myself going back to Xerces v2.0.2.
>
> Withdrawing from v2.4.0 and moving along the line of regression curve,
> I am concerned for the possible obstacles that may cause the project
> downtime. And the resression is not part of my nature, I am more to
> the progression same as many other folks in the open-source community.
>
> I am only using and intend to use(at least, for now) the XSD as standlone
> package. I wonder if the Eclipse/XSD is standalone package, would it
> make possible and simple to grab and use the later Xerces package? If so,
> would you think that making two different distributions -- one for as is
> now and another for standalone package that uses the later Xerces
> package.
>
> I would more than happy to hear about any other workarounds and/or
> comments for integrating the Eclipse/XSD with later Xerces package if
> you and/or other folks have. Thank you.
>
> Regards,
>
> Pae
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3EB8EB24.99F904DD@ca.ibm.com...
> > Pae,
> >
> > Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't move
> > along more quickly. But I have no control or influence over that. Part
> > of the problem here too is changes in Xerces that make it incompatible
> > from one version to the next. (I.e., the current Eclipse Xerces version
> > doesn't support a way to access the XML encoding without major hacking.)
> > But I have no control or influence over Xerces either.
> >
> > The concerns you express also affect IBM products like WSAD, which use
> > Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No matter
> > what happens, a version of Xerces must be chosen, XSD must be made to work
> > with that version, and anyone downstream (including WSAD) is bound by that
> > choice. If a newer version of Xerces comes along and XSD works with that
> > too, that's wonderful; but if it doesn't work with that version, then more
> > work needs to be done and a large number of folks all need to move to a
> > new version at once...
> >
> > I don't see a way for me to fix this, however much I may want to...
> >
> >
> > Pae Choi wrote:
> >
> > > I have noticed that we have some confusions/inconvenience
> > > or can cause the confusion/inconvenience as follows:
> > >
> > > 1.Eclipse uses the Xerces, but uses own version number. Would
> > > not it be better if we all use the same Xerces version?
> > > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > > So for those of who use the XSD as a standlone package, the
> > > restriction of (old) Xerces version is not relevant.
> > > 3. I am not sure for the rest of the XSD users, but I need to use
> > > the latest stable release of Xerces. And the XSD is an attractive
> > > package to use, but requres to use an old Xerces pacakge. This
> > > results to use two different Xerces packages. Not so good!
> > > 4. I understand that sync-ing with other team project is an important,
> > > but is XSD will always stuck with *old* Xerces if the usage of
> > > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > > at least a plan for it if so.
> > >
> > > I am not sure how others think about this, but I's certainly like
> > > to hear about this and resolve this for better. Thank you.
> > >
> > > Regards,
> > >
> > > Pae
> >


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Old Xerces Version [message #571252 is a reply to message #21743] Mon, 12 May 2003 13:20 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31362
Registered: July 2009
Senior Member
Bob,

I can imagine all too well. Sorry...

Bob Foster wrote:

> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3EB8EB24.99F904DD@ca.ibm.com...
> > I don't see a way for me to fix this, however much I may want to...
>
> Well, crap. I'm not blaming the messenger, but it is pretty ridiculous that
> this is being mishandled and no one on the planet is responsible.
>
> The version of xerces that ships with eclipse 2.1 (and 2.0) contains a bug
> that has been fixed in newer versions of both xerces and xml4j. The bug
> makes xerces not work with entityResolvers when schemas are parsed. (The
> same bug affected all documents in the recent past. It stemmed from the same
> misunderstanding of how entityResolvers work.)
>
> There seems to be no place to file a bug report about problems like this.
> Eclipse routinely ignores or closes them. Xml4j doesn't have the bug any
> more.
>
> If you (within IBM from whence these versions flow) feel helpless, imagine
> how it is for us. :-(
>
> Bob


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Old Xerces Version [message #571458 is a reply to message #21834] Tue, 13 May 2003 00:52 Go to previous message
Eclipse UserFriend
Originally posted by: paechoi.earthlink.net

Ed,

Thank you for your extra efforts as well as taking time in regarding on
this issue.

I can sense the chanllenges for migrating Eclipse/XSD with later Xerces
and understand that it is not an overnight task. I also understand you as
well are one of us who think and desire that we should take some action
for this issue. I am glad that at least we are in the same page.

I am not trying to be selfish here, but my main and a sole(for now) purpose
to *use* the Eclipse/XSD package is for XML Schema validation. And I am
getting feelings and feedbacks that retreating back to Xerces v2.0.2 is
getting out of option at my case.

I am not sure if your initial investigation was sufficient to provide me the
answers for the inquires as follows:

1. Is it possible and feasible to liberate from the Xerces v2.0.2?
2. If so, what kind of time frame you are looking at it in a rough
estimation?
3. This is specifically for my case. How difficult would it be if I extract
the mechanisms just for "Validation" out of it?

Regards,


Pae





"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3EBF99F1.FCD1CC88@ca.ibm.com...
> Pae,
>
> I tried getting the latest Xerces 2.4.0 to see what problems I have.
> Unfortunately there are many. XSD uses some of the Xerces datatypes for
> representing date values as well as things like HexBinary and
Base64Binary. All
> of these things look like they've changed in incompatible ways that will
require
> changes in XSD in order to for me to step up to the latest Xerces.
>
> Maintaining two versions of XSD in order to target two different versions
of
> Xerces is not something that I will be able to sustain with my very
limited
> available time.
>
>
> Pae Choi wrote:
>
> > Ed,
> >
> > I've been used the Xerces v2.2.1 for the projects I am involving at
> > present. And I was going to move out to the latest release of Xerces
> > such as v2.4.0 when the time comes.
> >
> > Since I am pretty much enjoying the Eclipse/XSD and planning to adop
> > it, I am seeing myself going back to Xerces v2.0.2.
> >
> > Withdrawing from v2.4.0 and moving along the line of regression curve,
> > I am concerned for the possible obstacles that may cause the project
> > downtime. And the resression is not part of my nature, I am more to
> > the progression same as many other folks in the open-source community.
> >
> > I am only using and intend to use(at least, for now) the XSD as
standlone
> > package. I wonder if the Eclipse/XSD is standalone package, would it
> > make possible and simple to grab and use the later Xerces package? If
so,
> > would you think that making two different distributions -- one for as is
> > now and another for standalone package that uses the later Xerces
> > package.
> >
> > I would more than happy to hear about any other workarounds and/or
> > comments for integrating the Eclipse/XSD with later Xerces package if
> > you and/or other folks have. Thank you.
> >
> > Regards,
> >
> > Pae
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3EB8EB24.99F904DD@ca.ibm.com...
> > > Pae,
> > >
> > > Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't
move
> > > along more quickly. But I have no control or influence over that.
Part
> > > of the problem here too is changes in Xerces that make it incompatible
> > > from one version to the next. (I.e., the current Eclipse Xerces
version
> > > doesn't support a way to access the XML encoding without major
hacking.)
> > > But I have no control or influence over Xerces either.
> > >
> > > The concerns you express also affect IBM products like WSAD, which use
> > > Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No
matter
> > > what happens, a version of Xerces must be chosen, XSD must be made to
work
> > > with that version, and anyone downstream (including WSAD) is bound by
that
> > > choice. If a newer version of Xerces comes along and XSD works with
that
> > > too, that's wonderful; but if it doesn't work with that version, then
more
> > > work needs to be done and a large number of folks all need to move to
a
> > > new version at once...
> > >
> > > I don't see a way for me to fix this, however much I may want to...
> > >
> > >
> > > Pae Choi wrote:
> > >
> > > > I have noticed that we have some confusions/inconvenience
> > > > or can cause the confusion/inconvenience as follows:
> > > >
> > > > 1.Eclipse uses the Xerces, but uses own version number. Would
> > > > not it be better if we all use the same Xerces version?
> > > > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > > > So for those of who use the XSD as a standlone package, the
> > > > restriction of (old) Xerces version is not relevant.
> > > > 3. I am not sure for the rest of the XSD users, but I need to use
> > > > the latest stable release of Xerces. And the XSD is an
attractive
> > > > package to use, but requres to use an old Xerces pacakge. This
> > > > results to use two different Xerces packages. Not so good!
> > > > 4. I understand that sync-ing with other team project is an
important,
> > > > but is XSD will always stuck with *old* Xerces if the usage of
> > > > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > > > at least a plan for it if so.
> > > >
> > > > I am not sure how others think about this, but I's certainly like
> > > > to hear about this and resolve this for better. Thank you.
> > > >
> > > > Regards,
> > > >
> > > > Pae
> > >
>
Re: Old Xerces Version [message #571558 is a reply to message #22056] Tue, 13 May 2003 09:25 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31362
Registered: July 2009
Senior Member
Pae,

Moving to a new version of Xerces will involve some changes in the XSDParser and
XSDResourceImpl, which do the parsing, as well as some changes in
org.eclipse.xsd.impl.type, which use Xerces schema types to implement XML Schema
values. The changes are relatively straight forward and I doubt would take more
than a day of effort. I'm not sure what you mean by separating "Validation"
out, but I doubt there's anything easily separable from the rest of the code.

A truly persistent person would be able to derive from XSDResourceImpl and
override doLoad to use a copied and changed version of XSDParser that works with
a different version of Xerces. They would also be able to create alternative
implementations of the types in org.eclipse.xsd.impl.type that work with a
different version of Xerces; these alternatives could be registered in the
XSDTypeRegister in that package...


Pae Choi wrote:

> Ed,
>
> Thank you for your extra efforts as well as taking time in regarding on
> this issue.
>
> I can sense the chanllenges for migrating Eclipse/XSD with later Xerces
> and understand that it is not an overnight task. I also understand you as
> well are one of us who think and desire that we should take some action
> for this issue. I am glad that at least we are in the same page.
>
> I am not trying to be selfish here, but my main and a sole(for now) purpose
> to *use* the Eclipse/XSD package is for XML Schema validation. And I am
> getting feelings and feedbacks that retreating back to Xerces v2.0.2 is
> getting out of option at my case.
>
> I am not sure if your initial investigation was sufficient to provide me the
> answers for the inquires as follows:
>
> 1. Is it possible and feasible to liberate from the Xerces v2.0.2?
> 2. If so, what kind of time frame you are looking at it in a rough
> estimation?
> 3. This is specifically for my case. How difficult would it be if I extract
> the mechanisms just for "Validation" out of it?
>
> Regards,
>
> Pae
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3EBF99F1.FCD1CC88@ca.ibm.com...
> > Pae,
> >
> > I tried getting the latest Xerces 2.4.0 to see what problems I have.
> > Unfortunately there are many. XSD uses some of the Xerces datatypes for
> > representing date values as well as things like HexBinary and
> Base64Binary. All
> > of these things look like they've changed in incompatible ways that will
> require
> > changes in XSD in order to for me to step up to the latest Xerces.
> >
> > Maintaining two versions of XSD in order to target two different versions
> of
> > Xerces is not something that I will be able to sustain with my very
> limited
> > available time.
> >
> >
> > Pae Choi wrote:
> >
> > > Ed,
> > >
> > > I've been used the Xerces v2.2.1 for the projects I am involving at
> > > present. And I was going to move out to the latest release of Xerces
> > > such as v2.4.0 when the time comes.
> > >
> > > Since I am pretty much enjoying the Eclipse/XSD and planning to adop
> > > it, I am seeing myself going back to Xerces v2.0.2.
> > >
> > > Withdrawing from v2.4.0 and moving along the line of regression curve,
> > > I am concerned for the possible obstacles that may cause the project
> > > downtime. And the resression is not part of my nature, I am more to
> > > the progression same as many other folks in the open-source community.
> > >
> > > I am only using and intend to use(at least, for now) the XSD as
> standlone
> > > package. I wonder if the Eclipse/XSD is standalone package, would it
> > > make possible and simple to grab and use the later Xerces package? If
> so,
> > > would you think that making two different distributions -- one for as is
> > > now and another for standalone package that uses the later Xerces
> > > package.
> > >
> > > I would more than happy to hear about any other workarounds and/or
> > > comments for integrating the Eclipse/XSD with later Xerces package if
> > > you and/or other folks have. Thank you.
> > >
> > > Regards,
> > >
> > > Pae
> > >
> > > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > > news:3EB8EB24.99F904DD@ca.ibm.com...
> > > > Pae,
> > > >
> > > > Yes, I'm pretty unhappy that the Xerces version in Eclipse doesn't
> move
> > > > along more quickly. But I have no control or influence over that.
> Part
> > > > of the problem here too is changes in Xerces that make it incompatible
> > > > from one version to the next. (I.e., the current Eclipse Xerces
> version
> > > > doesn't support a way to access the XML encoding without major
> hacking.)
> > > > But I have no control or influence over Xerces either.
> > > >
> > > > The concerns you express also affect IBM products like WSAD, which use
> > > > Eclipse (and XSD) and are bound by Eclipse's choice of Xerces. No
> matter
> > > > what happens, a version of Xerces must be chosen, XSD must be made to
> work
> > > > with that version, and anyone downstream (including WSAD) is bound by
> that
> > > > choice. If a newer version of Xerces comes along and XSD works with
> that
> > > > too, that's wonderful; but if it doesn't work with that version, then
> more
> > > > work needs to be done and a large number of folks all need to move to
> a
> > > > new version at once...
> > > >
> > > > I don't see a way for me to fix this, however much I may want to...
> > > >
> > > >
> > > > Pae Choi wrote:
> > > >
> > > > > I have noticed that we have some confusions/inconvenience
> > > > > or can cause the confusion/inconvenience as follows:
> > > > >
> > > > > 1.Eclipse uses the Xerces, but uses own version number. Would
> > > > > not it be better if we all use the same Xerces version?
> > > > > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > > > > So for those of who use the XSD as a standlone package, the
> > > > > restriction of (old) Xerces version is not relevant.
> > > > > 3. I am not sure for the rest of the XSD users, but I need to use
> > > > > the latest stable release of Xerces. And the XSD is an
> attractive
> > > > > package to use, but requres to use an old Xerces pacakge. This
> > > > > results to use two different Xerces packages. Not so good!
> > > > > 4. I understand that sync-ing with other team project is an
> important,
> > > > > but is XSD will always stuck with *old* Xerces if the usage of
> > > > > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > > > > at least a plan for it if so.
> > > > >
> > > > > I am not sure how others think about this, but I's certainly like
> > > > > to hear about this and resolve this for better. Thank you.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Pae
> > > >
> >


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Old Xerces Version [message #573067 is a reply to message #21316] Wed, 18 June 2003 00:04 Go to previous message
Mike Dickson is currently offline Mike DicksonFriend
Messages: 8
Registered: July 2009
Junior Member
Does eclipse have any notion of multiple versions of a package as plugins?
That is, could you package up the newer version of Xerces as a plugin with
different version info and make the XSD stuff dependant on it while core
eclipse continues to use the old version. This would of course require some
flexibility in classloading but it is possible and it would help obviate
problems like this where XSD is stuck and kept from moving ahead because of
an old version in eclipse.

Mike

"Pae Choi" <paechoi@earthlink.net> wrote in message
news:b9ak8q$oam$1@rogue.oti.com...
> I have noticed that we have some confusions/inconvenience
> or can cause the confusion/inconvenience as follows:
>
> 1.Eclipse uses the Xerces, but uses own version number. Would
> not it be better if we all use the same Xerces version?
> 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> So for those of who use the XSD as a standlone package, the
> restriction of (old) Xerces version is not relevant.
> 3. I am not sure for the rest of the XSD users, but I need to use
> the latest stable release of Xerces. And the XSD is an attractive
> package to use, but requres to use an old Xerces pacakge. This
> results to use two different Xerces packages. Not so good!
> 4. I understand that sync-ing with other team project is an important,
> but is XSD will always stuck with *old* Xerces if the usage of
> Xerces in the Eclipse Editor remain as is? Don't we need to have
> at least a plan for it if so.
>
> I am not sure how others think about this, but I's certainly like
> to hear about this and resolve this for better. Thank you.
>
> Regards,
>
>
> Pae
>
>
>
Re: Old Xerces Version [message #573151 is a reply to message #23717] Wed, 18 June 2003 10:49 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31362
Registered: July 2009
Senior Member
Michael,

It's possible, but it presents it's own problems since the DOM produced by XSD
might be used by some code that depends explicitly on a different version of
Xerces or the DOM from some other version of Xerces might be passed to XSD.
IBM's WSAD has been careful to avoid this type of problem, so I don't want to be
the one who reintroduces it. I don't think I could get the agreement, even if I
did try. I was only able to get an upgrade to Xerces 4.0.13 to happen, and that
turned out to be of little advantage...


Michael Dickson wrote:

> Does eclipse have any notion of multiple versions of a package as plugins?
> That is, could you package up the newer version of Xerces as a plugin with
> different version info and make the XSD stuff dependant on it while core
> eclipse continues to use the old version. This would of course require some
> flexibility in classloading but it is possible and it would help obviate
> problems like this where XSD is stuck and kept from moving ahead because of
> an old version in eclipse.
>
> Mike
>
> "Pae Choi" <paechoi@earthlink.net> wrote in message
> news:b9ak8q$oam$1@rogue.oti.com...
> > I have noticed that we have some confusions/inconvenience
> > or can cause the confusion/inconvenience as follows:
> >
> > 1.Eclipse uses the Xerces, but uses own version number. Would
> > not it be better if we all use the same Xerces version?
> > 2. Some of us use the XSD as a standalone, not with Eclipse Editor.
> > So for those of who use the XSD as a standlone package, the
> > restriction of (old) Xerces version is not relevant.
> > 3. I am not sure for the rest of the XSD users, but I need to use
> > the latest stable release of Xerces. And the XSD is an attractive
> > package to use, but requres to use an old Xerces pacakge. This
> > results to use two different Xerces packages. Not so good!
> > 4. I understand that sync-ing with other team project is an important,
> > but is XSD will always stuck with *old* Xerces if the usage of
> > Xerces in the Eclipse Editor remain as is? Don't we need to have
> > at least a plan for it if so.
> >
> > I am not sure how others think about this, but I's certainly like
> > to hear about this and resolve this for better. Thank you.
> >
> > Regards,
> >
> >
> > Pae
> >
> >
> >


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Old Xerces Version [message #573202 is a reply to message #22197] Thu, 19 June 2003 16:16 Go to previous message
Stefano Turri is currently offline Stefano TurriFriend
Messages: 1
Registered: July 2009
Junior Member
Hi,

I'm trying to use XSD in a standalone project (not using Eclipse), and I'm
having some problems, since the this project uses Xerces 2.4.0.

The XML parsing seems Ok (I Havent't found any problem yet), and the
problems appear only when validating simple type values.

Following your suggestion I'm registering alternative type implementation
(based on Xerces 2.4.0) to replace the one in org.eclipse.xsd.impl.type
based on Xerces 2.0.x. This is solving the validation problem, and permits
the use of Xerces 2.4.0. Are there any other kind of side effects I shuld
be aware of in doing this?

Perhaps the type classes in org.eclipse.xsd.impl.type might be release in
a different separate jar, and XSD might be able to switch between 2.0.x
and 2.x.x only changing between different version of this support jar,
while keeping the core XSD in its own jar.

Regards,
Stefano Turri



Ed Merks wrote:

> A truly persistent person would be able to derive from XSDResourceImpl and
> override doLoad to use a copied and changed version of XSDParser that works
with
> a different version of Xerces. They would also be able to create alternative
> implementations of the types in org.eclipse.xsd.impl.type that work with a
> different version of Xerces; these alternatives could be registered in the
> XSDTypeRegister in that package...
Re: Old Xerces Version [message #573263 is a reply to message #23845] Thu, 19 June 2003 16:45 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31362
Registered: July 2009
Senior Member
Stefano,

I'm very glad (and impressed) that you found workarounds that help to get you
going! Although your suggestion for how to handle multiple version of Xerces is a
good one, we are too late in the 1.1.0 development cycle to make changes like this
(and my spare cycles to address this are nonexistent). We could also try to do
things via reflection so that one code base works against multiple versions of
Xerces, but again, I haven't had the time to follow up on that. I'm hopeful that
folks will bear with me and that this problem will be eliminated in Eclipse 3.0
when the Eclipse 2.1.1 work is complete...

Stefano Turri wrote:

> Hi,
>
> I'm trying to use XSD in a standalone project (not using Eclipse), and I'm
> having some problems, since the this project uses Xerces 2.4.0.
>
> The XML parsing seems Ok (I Havent't found any problem yet), and the
> problems appear only when validating simple type values.
>
> Following your suggestion I'm registering alternative type implementation
> (based on Xerces 2.4.0) to replace the one in org.eclipse.xsd.impl.type
> based on Xerces 2.0.x. This is solving the validation problem, and permits
> the use of Xerces 2.4.0. Are there any other kind of side effects I shuld
> be aware of in doing this?
>
> Perhaps the type classes in org.eclipse.xsd.impl.type might be release in
> a different separate jar, and XSD might be able to switch between 2.0.x
> and 2.x.x only changing between different version of this support jar,
> while keeping the core XSD in its own jar.
>
> Regards,
> Stefano Turri
>
> Ed Merks wrote:
>
> > A truly persistent person would be able to derive from XSDResourceImpl and
> > override doLoad to use a copied and changed version of XSDParser that works
> with
> > a different version of Xerces. They would also be able to create alternative
> > implementations of the types in org.eclipse.xsd.impl.type that work with a
> > different version of Xerces; these alternatives could be registered in the
> > XSDTypeRegister in that package...


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:XML Schema Equivalence
Next Topic:Call Hierarchy, short key and osx
Goto Forum:
  


Current Time: Sun Aug 09 18:56:23 GMT 2020

Powered by FUDForum. Page generated in 0.02651 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top