You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@xmlbeans.apache.org by Jacob Danner <ja...@gmail.com> on 2007/12/01 06:17:52 UTC

Re: just a version change in namespaces causes so much difficulties?

Versioning is always a tricky thing. I'm sure there are plenty of
users on the list that can chime in with there solutions to similar
issues.
As far as what you might be able to do to alleviate some of your
headache, try an xsdconfig file. That way you can map a namespace to a
package name and at least make things a little simpler from a java
code perspective.
Otherwise you may wanna try using the XmlOptions or cursor API to
manipulate the instance with all the namespaces you need.
Anyone else have any suggestions?
-jacobd

On 11/30/07, Johannes Echterhoff <Jo...@gmx.de> wrote:
> Hello.
>
> We are developing a web service (A) which uses a set of schema for
> encoding and decoding incoming requests. One part of these schema is in
> the namespace http://www.opengis.net/swe/1.0. Now, the service depends
> upon another service (B), so is requesting information from that
> service. Parts of that information should just be inserted in the
> services own metadata. So what I would like to do is just to copy the
> relevant xml elements that have been received from B into the according
> xml instances of A. However, what is to be copied comes from a previous
> schema version than what service A uses. The namespace for schema that
> service B uses is http://www.opengis.net/0.0. The elements that we would
> like to copy differ only by the namespace. Whenever I want to just set
> elements retrieved from service B in an xml instance of service A, a
> conflict of namespaces occurs.
>
> Is there an easy way to circumvent this problem, i.e. to copy the
> contents belonging to http://www.opengis.net/swe/0.0 to a new instance
> of http://www.opengis.net/swe/1.0? The brute force approach right now is
> to create extra code which generates a new 1.0 copy of the 0.0 element.
>
> Best regards,
> Johannes Echterhoff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: user-help@xmlbeans.apache.org
>
>

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