Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Multiple XSDs with identical targetNamespaces
Multiple XSDs with identical targetNamespaces [message #74364] Thu, 15 May 2008 08:28 Go to next message
Zsolt Török is currently offline Zsolt Török
Messages: 22
Registered: July 2009
Junior Member
I'm using openArchitectureWare's XSD adapter to gain access to a couple of
XSDs, which uses the EMF XSD plugin to transform the schemas into Ecore.
I'm working with a set of interrelated XSDs, which have the same
targetNamespace specified.
When importing these through XSDEcoreBuilder the getEPackage(...) method
uses the same key (the above mentioned targetNamespace) when storing the
created EPackages to a HashMap, therefore constantly overwriting the
previous EPackage.

I also experimented with stripping away the targetNamespaces from the
XSDs, which resulted in even stranger behaviour: the first EPackage
without targetNamespace got stored in the HashMap with a null key. I could
only get it to work when I modified the targetNamespaces to be unique, but
since the XSDs are part of a standard I can't change them just like that.

Could this be worth a bug report? If so, what would be the approximate
timeframe for fixing it? By looking at the code I'd say this fix is
non-trivial, because we need to find some other, unique key to put in the
above mentioned HashMap instead of the targetNamespace. Any ideas,
suggestions welcome!

Thanks,
Zsolt
Re: Multiple XSDs with identical targetNamespaces [message #74384 is a reply to message #74364] Thu, 15 May 2008 13:51 Go to previous message
Eclipse User
Originally posted by: merks.ca.ibm.com

Zsolt,

Comments below

Zsolt Török wrote:
> I'm using openArchitectureWare's XSD adapter to gain access to a
> couple of XSDs, which uses the EMF XSD plugin to transform the schemas
> into Ecore. I'm working with a set of interrelated XSDs, which have
> the same targetNamespace specified.
> When importing these through XSDEcoreBuilder the getEPackage(...)
> method uses the same key (the above mentioned targetNamespace) when
> storing the created EPackages to a HashMap, therefore constantly
> overwriting the previous EPackage.
If you use a single instance of the builder it should create a single
package of the overall combined results for that namespace.
>
> I also experimented with stripping away the targetNamespaces from the
> XSDs, which resulted in even stranger behaviour: the first EPackage
> without targetNamespace got stored in the HashMap with a null key. I
> could only get it to work when I modified the targetNamespaces to be
> unique, but since the XSDs are part of a standard I can't change them
> just like that.
They really do need to be merged into a single result.
>
> Could this be worth a bug report?
I suspect it's a usage problem and not an intrinsic one... Repeated
called to getEPackage should return the same package.
> If so, what would be the approximate timeframe for fixing it? By
> looking at the code I'd say this fix is non-trivial, because we need
> to find some other, unique key to put in the above mentioned HashMap
> instead of the targetNamespace. Any ideas, suggestions welcome!
It's important that the schema's target namespace map to the EPackage's
nsURI. In the final application these are not only the keys for finding
the package but also the namespaces used to serialize the instances so
that they conform to the schema.

Probably you need to talk to the oAW guys about how they are using the
building. Likely they need to use one instance of the builder in your
scenario...
>
> Thanks,
> Zsolt
>
Re: Multiple XSDs with identical targetNamespaces [message #603008 is a reply to message #74364] Thu, 15 May 2008 13:51 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
Zsolt,

Comments below

Zsolt Török wrote:
> I'm using openArchitectureWare's XSD adapter to gain access to a
> couple of XSDs, which uses the EMF XSD plugin to transform the schemas
> into Ecore. I'm working with a set of interrelated XSDs, which have
> the same targetNamespace specified.
> When importing these through XSDEcoreBuilder the getEPackage(...)
> method uses the same key (the above mentioned targetNamespace) when
> storing the created EPackages to a HashMap, therefore constantly
> overwriting the previous EPackage.
If you use a single instance of the builder it should create a single
package of the overall combined results for that namespace.
>
> I also experimented with stripping away the targetNamespaces from the
> XSDs, which resulted in even stranger behaviour: the first EPackage
> without targetNamespace got stored in the HashMap with a null key. I
> could only get it to work when I modified the targetNamespaces to be
> unique, but since the XSDs are part of a standard I can't change them
> just like that.
They really do need to be merged into a single result.
>
> Could this be worth a bug report?
I suspect it's a usage problem and not an intrinsic one... Repeated
called to getEPackage should return the same package.
> If so, what would be the approximate timeframe for fixing it? By
> looking at the code I'd say this fix is non-trivial, because we need
> to find some other, unique key to put in the above mentioned HashMap
> instead of the targetNamespace. Any ideas, suggestions welcome!
It's important that the schema's target namespace map to the EPackage's
nsURI. In the final application these are not only the keys for finding
the package but also the namespaces used to serialize the instances so
that they conform to the schema.

Probably you need to talk to the oAW guys about how they are using the
building. Likely they need to use one instance of the builder in your
scenario...
>
> Thanks,
> Zsolt
>
Previous Topic:Multiple XSDs with identical targetNamespaces
Next Topic:XML Schema Comparison
Goto Forum:
  


Current Time: Mon Sep 22 00:31:41 GMT 2014

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

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