| Problem using un-unique URIs as Identifier [message #662566] |
Thu, 31 March 2011 07:24  |
|
Hi,
I created an ecore model from an existing XSD schema which worked very well. Now this schema has changed and I want to support both versions. So I created a project for each version und ran them seperately as Eclipse Applications. No Problem so far.
But when I open both projects and run them, only files using one version can be opened properly. Because both versions use the same URI and both applications register their packages using this URI as key. The console output displays something like:
!MESSAGE Both 'version0' and 'version1' register a package for 'http://example.org/sample'
My second thought was to register the packages against something else, eg against a content type? That would be really unique!
Thanks for any help and hints!
Kai
|
|
|
| Re: Problem using un-unique URIs as Identifier [message #662702 is a reply to message #662566] |
Thu, 31 March 2011 15:40  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Kai,
Comments below.
Kai B. Heinz wrote:
> Hi,
> I created an ecore model from an existing XSD schema which worked very
> well. Now this schema has changed and I want to support both versions.
How has it changed?
> So I created a project for each version und ran them seperately as
> Eclipse Applications. No Problem so far.
> But when I open both projects and run them, only files using one
> version can be opened properly. Because both versions use the same URI
> and both applications register their packages using this URI as key.
Indeed.
> The console output displays something like: !MESSAGE Both 'version0'
> and 'version1' register a package for 'http://example.org/sample'So
> the solution seems as easy as hard for me. The keys must be unique.
> Just renaming them is no solution because source files can be
> generated by foreign applications which support the official standard,
> not my individual one. My second thought was to register the packages
> against something else, eg against a content type? That would be
> really unique!
How will you be able to tell, given a file (XML instance), which
instance of the package to use? Normally when schemas evolve, they
either do so in a binary compatible way, i.e., nothing is removed, only
new things are added (so you can use the new model to read old
instances), or they must change their version by using a new namespace.
>
> Thanks for any help and hints!
>
> Kai
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem using un-unique URIs as Identifier [message #662827 is a reply to message #662702] |
Fri, 01 April 2011 06:33 |
|
The schema changed in several ways. Some objects are added, others are removed. It is not just the old one plus something more! This happens because it is a drafted standard by now. The cover sheet tells:
| Quote: | Warning
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice (...)
|
Nevertheless it is used and I should support it, they don't care how.
Yesterday I read a lot about dynamic EMF and that it is possible to register packages locally within a resource-set. Could that solve my problems?
Thank you!
Kai
|
|
|
| Re: Problem using un-unique URIs as Identifier [message #662966 is a reply to message #662827] |
Fri, 01 April 2011 15:17 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070302090303020004030604
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Kai,
Comments below.
Kai B. Heinz wrote:
> The schema changed in several ways. Some objects are added, others are
> removed. It is not just the old one plus something more! This happens
> because it is a drafted standard by now. The cover sheet tells:
> Quote:
>> Warning
>> This document is not an ISO International Standard. It is distributed
>> for review and comment. It is subject to change without notice (...)
> Nevertheless it is used and I should support it, they don't care how.
You could pass on this caveat to your consumers. :-P
YOu could also just use only the new model with this option
/**
* This options allows you to record unknown features during
deserialization/loading.
* The default is <code>Boolean.FALSE</code> unless set to
<code>Boolean.TRUE</code> explicitly.
* The unknown features and their values can be accessed via
getEObjectToExtensionMap().
* @see #getEObjectToExtensionMap()
*/
String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";
to capture the old stuff.
> Yesterday I read a lot about dynamic EMF and that it is possible to
> register packages locally within a resource-set. Could that solve my
> problems?
Potentially, but the question remains, how will you know which version
of the package to use when reading any particular instance?
>
> Thank you!
> Kai
--------------070302090303020004030604
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Kai,<br>
<br>
Comments below.<br>
<br>
<br>
Kai B. Heinz wrote:
<blockquote cite="mid:in3r75$1uj$1@news.eclipse.org" type="cite">The
schema changed in several ways. Some objects are added, others are
removed. It is not just the old one plus something more! This happens
because it is a drafted standard by now. The cover sheet tells:
<br>
Quote:
<br>
<blockquote type="cite">Warning
<br>
This document is not an ISO International Standard. It is distributed
for review and comment. It is subject to change without notice (...)
<br>
</blockquote>
Nevertheless it is used and I should support it, they don't care how.
<br>
</blockquote>
You could pass on this caveat to your consumers. :-P<br>
<br>
YOu could also just use only the new model with this option<br>
<blockquote><small> /**</small><br>
<small> * This options allows you to record unknown features during
deserialization/loading.</small><br>
<small> * The default is <code>Boolean.FALSE</code>
unless set to <code>Boolean.TRUE</code> explicitly. </small><br>
<small> * The unknown features and their values can be accessed via
getEObjectToExtensionMap().</small><br>
<small> * @see #getEObjectToExtensionMap() </small><br>
<small> */</small><br>
<small> String OPTION_RECORD_UNKNOWN_FEATURE =
"RECORD_UNKNOWN_FEATURE";</small><br>
</blockquote>
to capture the old stuff.<br>
<br>
<br>
<blockquote cite="mid:in3r75$1uj$1@news.eclipse.org" type="cite">Yesterday
I read a lot about dynamic EMF and that it is possible to register
packages locally within a resource-set. Could that solve my problems?
<br>
</blockquote>
Potentially, but the question remains, how will you know which version
of the package to use when reading any particular instance?<br>
<blockquote cite="mid:in3r75$1uj$1@news.eclipse.org" type="cite">
<br>
Thank you!
<br>
Kai
<br>
</blockquote>
</body>
</html>
--------------070302090303020004030604--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem using un-unique URIs as Identifier [message #666213 is a reply to message #662966] |
Tue, 19 April 2011 13:52 |
|
Finally I used another approach to solve the problem. Before generating the model code, I change the URIs in the genmodel and made them unique (uri = uri + version). Hence this URI is just an 'internal' URI I overrode the parser handler. So if the handler finds the namespace and version attribute it will create the internal URI.
Now I can load and edit files from different versions.
One last problem occurs when saving the files. By now EMF puts the internal URI in the document root, but actually I want the original one. I thought I could override the save method in the XXXResourceImpl, search for the internal URI in the prefix map, change URI back to original URI and finally call super.save(...). But this results in a document root with 2 URIs, one prefixed (the internal one) and one not (the other, original one). How can I get just the original one back to the root element?
Thanks
Kai
|
|
|
| Re: Problem using un-unique URIs as Identifier [message #666229 is a reply to message #666213] |
Tue, 19 April 2011 14:17 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Kai,
If you're using the OPTION_EXTENDED_META_DATA you could specialize it's
getNamespace method to return the one you really want.
Kai B. Heinz wrote:
> Finally I used another approach to solve the problem. Before
> generating the model code, I change the URIs in the genmodel and made
> them unique (uri = uri + version). Hence this URI is just an
> 'internal' URI I overrode the parser handler. So if the handler finds
> the namespace and version attribute it will create the internal URI.
> Now I can load and edit files from different versions. One last
> problem occurs when saving the files. By now EMF puts the internal URI
> in the document root, but actually I want the original one. I thought
> I could override the save method in the XXXResourceImpl, search for
> the internal URI in the prefix map, change URI back to original URI
> and finally call super.save(...). But this results in a document root
> with 2 URIs, one prefixed (the internal one) and one not (the other,
> original one). How can I get just the original one back to the root
> element?
>
> Thanks
> Kai
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03467 seconds
] 
Search
Help
Register
Login
Home
