Home » Modeling » EMF » Use different nsURI during save
| Use different nsURI during save [message #517588] |
Mon, 01 March 2010 12:41  |
 Daniel Weber
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi all,
I'd like to save a model as XML and change the nsURI it uses to
reference a specific metamodel. This metamodel (GMF's notation model,
but please read on, I still consider this an EMF question ;)) has been
changed, uses a new version and a different namespace URI. My "old"
files (before switching to the new GMF version) start like this:
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI [...] xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.1/notation">
If I load such a file with the new version and save it, this changes to:
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI [...] xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.2/notation">
I.e. the version changed to 1.0.2. Which is perfectly fine in general.
It's just that I cannot open this newly saved file with older versions
of our editor, which is critical to us. Now, what I'd like to do is
change the namespace URI used to reference the notation model during
save so that it points to the previous version instead of the current one
(let's just assume I can limit this to cases where the model actually is
compatible to the old notation metamodel). A solution I found was to
"inject" some extended metadata:
saveOptions.put(XMLResource.OPTION_EXTENDED_META_DATA,
new BasicExtendedMetaData(){
@Override
public String getNamespace(EPackage ePackage)
{
if (NotationPackage.eINSTANCE == ePackage)
{
return "http://www.eclipse.org/gmf/runtime/1.0.1/notation";
}
return super.getNamespace(ePackage);
}
});
Which seems to do the trick, but I'm not sure what else is influenced
by this change. Is this the way to go or is there a better option?
Regards,
Daniel
|
|
|
| Re: Use different nsURI during save [message #517601 is a reply to message #517588] |
Mon, 01 March 2010 14:02  |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Daniel,
Comments below.
Daniel Weber wrote:
> Hi all,
>
> I'd like to save a model as XML and change the nsURI it uses to
> reference a specific metamodel. This metamodel (GMF's notation model,
> but please read on, I still consider this an EMF question ;)) has been
> changed, uses a new version and a different namespace URI. My "old"
> files (before switching to the new GMF version) start like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xmi:XMI [...]
> xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.1/notation">
>
> If I load such a file with the new version and save it, this changes to:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xmi:XMI [...]
> xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.2/notation">
>
> I.e. the version changed to 1.0.2. Which is perfectly fine in general.
> It's just that I cannot open this newly saved file with older versions
> of our editor, which is critical to us. Now, what I'd like to do is
> change the namespace URI used to reference the notation model during
> save so that it points to the previous version instead of the current
> one (let's just assume I can limit this to cases where the model
> actually is compatible to the old notation metamodel). A solution I
> found was to "inject" some extended metadata:
>
> saveOptions.put(XMLResource.OPTION_EXTENDED_META_DATA,
> new BasicExtendedMetaData(){
> @Override
> public String getNamespace(EPackage ePackage)
> {
> if (NotationPackage.eINSTANCE == ePackage)
> {
> return "http://www.eclipse.org/gmf/runtime/1.0.1/notation";
> }
> return super.getNamespace(ePackage);
> }
> });
>
> Which seems to do the trick, but I'm not sure what else is influenced
> by this change. Is this the way to go or is there a better option?
Yes, that's what I would have suggested. Of course the namespace
probably changed for a good reason, i.e., something was added to the
model, so it might well be that you'll still end up with a problem if
you inadvertently end up using that added thing. An alternative would
have been to register the new namespace against the older package in
your older editor, but that of course would require you to redeploy it,
so I could see that being less than ideal.
>
> Regards,
> Daniel
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Use different nsURI during save [message #517617 is a reply to message #517601] |
Mon, 01 March 2010 14:32 |
Daniel Weber
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi Ed,
thanks for the quick answer :)
Ed Merks wrote:
> [...]
> Yes, that's what I would have suggested. Of course the namespace
> probably changed for a good reason, i.e., something was added to the
> model, so it might well be that you'll still end up with a problem if
> you inadvertently end up using that added thing.
Yes, I am aware of that. I'd like to stick with the old namespace URI as long
as we're not using anything from the new metamodel version. If we start using
new features, there's no way around the new URI, but then it is also justified.
And old editors would not be able to cope with the information in there anyway
(most probably...).
> An alternative would
> have been to register the new namespace against the older package in
> your older editor, but that of course would require you to redeploy it,
> so I could see that being less than ideal.
> [...]
Yeah, that'd be too painful.
Cheers,
Daniel
|
|
|
| Re: Use different nsURI during save [message #517630 is a reply to message #517617] |
Mon, 01 March 2010 14:47 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050707070502030501070207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
This option can be useful to make your tools forward compatible:
/**
* 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";
It doesn't solve this namespace problem, but any attributes or elements
that aren't recognized are simply recorded in an associated map and are
injected back into the serialization when saving.
Daniel Weber wrote:
> Hi Ed,
>
> thanks for the quick answer :)
>
> Ed Merks wrote:
>> [...]
>> Yes, that's what I would have suggested. Of course the namespace
>> probably changed for a good reason, i.e., something was added to the
>> model, so it might well be that you'll still end up with a problem if
>> you inadvertently end up using that added thing.
>
> Yes, I am aware of that. I'd like to stick with the old namespace URI
> as long
> as we're not using anything from the new metamodel version. If we
> start using new features, there's no way around the new URI, but then
> it is also justified.
> And old editors would not be able to cope with the information in
> there anyway (most probably...).
>
>> An alternative would have been to register the new namespace against
>> the older package in your older editor, but that of course would
>> require you to redeploy it, so I could see that being less than ideal.
>> [...]
>
> Yeah, that'd be too painful.
> Cheers,
> Daniel
--------------050707070502030501070207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel,<br>
<br>
This option can be useful to make your tools forward compatible:<br>
<blockquote> /**<br>
* This options allows you to record unknown features during
deserialization/loading.<br>
* The default is <code>Boolean.FALSE</code> unless set
to <code>Boolean.TRUE</code> explicitly. <br>
* The unknown features and their values can be accessed via
getEObjectToExtensionMap().<br>
* @see #getEObjectToExtensionMap() <br>
*/<br>
String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";<br>
</blockquote>
It doesn't solve this namespace problem, but any attributes or elements
that aren't recognized are simply recorded in an associated map and are
injected back into the serialization when saving. <br>
<br>
<br>
Daniel Weber wrote:
<blockquote cite="mid:hmgj65$lnd$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
<br>
thanks for the quick answer :)
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">[...]
<br>
Yes, that's what I would have suggested. Of course the namespace
probably changed for a good reason, i.e., something was added to the
model, so it might well be that you'll still end up with a problem if
you inadvertently end up using that added thing. </blockquote>
<br>
Yes, I am aware of that. I'd like to stick with the old namespace URI
as long
<br>
as we're not using anything from the new metamodel version. If we start
using new features, there's no way around the new URI, but then it is
also justified.
<br>
And old editors would not be able to cope with the information in there
anyway (most probably...).
<br>
<br>
<blockquote type="cite">An alternative would have been to register
the new namespace against the older package in your older editor, but
that of course would require you to redeploy it, so I could see that
being less than ideal.
<br>
[...]
<br>
</blockquote>
<br>
Yeah, that'd be too painful. <br>
Cheers,
<br>
Daniel
<br>
</blockquote>
</body>
</html>
--------------050707070502030501070207--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 20:53:09 GMT 2024
Powered by FUDForum. Page generated in 0.01384 seconds |
] 
Search
Help
Register
Login
Home
