| Multiple XSDs with identical targetNamespaces [message #74364] |
Thu, 15 May 2008 08:28  |
 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  |
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 |
Ed Merks
Messages: 33140
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02907 seconds
] 
Search
Help
Register
Login
Home
