Home » Modeling » EMF » Problems with XMLMap, XMLInfo and ExtendedMetaData
| Problems with XMLMap, XMLInfo and ExtendedMetaData [message #428360] |
Wed, 18 March 2009 07:55  |
 Tiziano Leidi
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Dear All,
we are facing following problem:
some of our code uses following functionality of EMF:
final XMLInfo info = new XMLInfoImpl();
info.setTargetNamespace(targetNameSpace);
info.setName(targetName);
final XMLMap xmlMap = new XMLMapImpl();
xmlMap.add(classifier, info);
final Map<String, XMLMap> options = new HashMap<String, XMLMap>();
options.put(XMLResource.OPTION_XML_MAP, xmlMap);
Recently we needed to introduce ExtendedMetaData as a further option
due to a bug in the JAXP-Xerces discussed in this forum.
The problem we have now is that both approaches do not work together.
In class XMLHelperImpl at line 672 there's the following code:
public String getName(ENamedElement obj)
{
if (extendedMetaData != null)
{
return
obj instanceof EStructuralFeature ?
extendedMetaData.getName((EStructuralFeature)obj) :
extendedMetaData.getName((EClassifier)obj);
}
if (xmlMap != null)
{
XMLResource.XMLInfo info = xmlMap.getInfo(obj);
if (info != null)
{
String result = info.getName();
if (result != null)
{
return result;
}
}
}
If extended meta data exists, then the name contained in XMLInfo is
ignored because the code directly returns when handling
ExtendedMetaData.
Is this correct?
We tryied to use ExtendedMetaData as an alternative to modify name and
namespace in some of our EMF files, but ExtendedMetaData stores the
modification persistently in packages and this is not what we need.
What we do with the code exploiting XMLMap, is to convert between
different kind of EMF Resources that are very similar (they extends
themeselves), therefore we just need to change name and namespace to
do the conversion (save the file) and not persistently.
Is the XMLInfo + XMLMap still the correct approach?
Is it possible to use ExtendedMetaData to do such kind of conversions
and therefore set a different name and namespace just for a moment to
save a resource to a different type instead of modifing them
persistently?
Is there maybe an alternative approach?
Many Thanks
BYE
Tiz
|
|
|
| Re: Problems with XMLMap, XMLInfo and ExtendedMetaData [message #428364 is a reply to message #428360] |
Wed, 18 March 2009 11:59  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tiziano,
Comments below.
Tiziano Leidi wrote:
> Dear All,
> we are facing following problem:
>
> some of our code uses following functionality of EMF:
>
> final XMLInfo info = new XMLInfoImpl();
> info.setTargetNamespace(targetNameSpace);
> info.setName(targetName);
> final XMLMap xmlMap = new XMLMapImpl();
> xmlMap.add(classifier, info);
> final Map<String, XMLMap> options = new HashMap<String, XMLMap>();
> options.put(XMLResource.OPTION_XML_MAP, xmlMap);
>
XML maps are superseded by extended metadata, which is far more powerful
and flexible.
> Recently we needed to introduce ExtendedMetaData as a further option
> due to a bug in the JAXP-Xerces discussed in this forum.
>
> The problem we have now is that both approaches do not work together.
>
No, exactly.
> In class XMLHelperImpl at line 672 there's the following code:
>
> public String getName(ENamedElement obj)
> {
> if (extendedMetaData != null)
> {
> return
> obj instanceof EStructuralFeature ?
> extendedMetaData.getName((EStructuralFeature)obj) :
> extendedMetaData.getName((EClassifier)obj);
> }
>
> if (xmlMap != null)
> {
> XMLResource.XMLInfo info = xmlMap.getInfo(obj);
> if (info != null)
> {
> String result = info.getName();
> if (result != null)
> {
> return result;
> }
> }
> }
>
> If extended meta data exists, then the name contained in XMLInfo is
> ignored because the code directly returns when handling
> ExtendedMetaData.
>
> Is this correct?
>
Yes.
> We tryied to use ExtendedMetaData as an alternative to modify name and
> namespace in some of our EMF files, but ExtendedMetaData stores the
> modification persistently in packages and this is not what we need.
>
So don't call setters on it. Just specialize the getters so they
return the right things.
> What we do with the code exploiting XMLMap, is to convert between
> different kind of EMF Resources that are very similar (they extends
> themeselves), therefore we just need to change name and namespace to
> do the conversion (save the file) and not persistently.
>
Specializing getElement/getAttribute should do the trick.
> Is the XMLInfo + XMLMap still the correct approach?
> Is it possible to use ExtendedMetaData to do such kind of conversions
> and therefore set a different name and namespace just for a moment to
> save a resource to a different type instead of modifing them
> persistently?
>
You can specialize it to return something different for getNamespace
than it would otherwise return.
> Is there maybe an alternative approach?
>
ExtendedMetaData is by far more powerful and you didn't should be able
to make what you're doing work by specializing things like
getElement/getAttribute when deserializing and things like getName and
getNamespace when serializing.
> Many Thanks
> BYE
> Tiz
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Problems with XMLMap, XMLInfo and ExtendedMetaData [message #428371 is a reply to message #428368] |
Wed, 18 March 2009 14:42 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tiz,
Comments below.
Tiziano Leidi wrote:
> Hi Ed,
> many, many thanks for the advice.
> The solution you proposed works very well for the name of the
> Classifier, by overriding the method
> String getName(EClassifier eClassifier);
> we are now able to modifiy the name during save.
>
> We tryed to do the same with the namespace, but the method
> String getNamespace(EClassifier eClassifier);
> is never called during serialization (just called when using setters
> on the ExtendedMetaData)
> The method
> String getNamespace(EPackage ePackage);
> is called instead.
>
I suppose it's a basic assumption that the classifiers of a package will
have that package's namespace. Because of XML Schema element and
attribute references, that's not true of features in the classes...
> Which one is the correct approach in this situation? Is the namespace
> for an EClassifier alway asked through
> String getNamespace(EPackage ePackage);
> just after the call to
> String getName(EClassifier eClassifier);
> ?
>
That's how it's implemented and I can see that a framework might assume
that. The serializer code has evolved a lot over the years, so
bypassing the getQName(EPackage, String) method could be bad.
> To explain our doubt:
> if the association is not 1-to-1 we risk modifing the namespace for
> Classifiers that are in the same resource but need to keep under the
> original namespace.
>
You're only needing to correct certain classifiers?
> Furthermore we experience a strange behaviour: When overriding the
> method
> String getNamespace(EPackage ePackage);
> the code located in Class XMLHelperImpl at line 566:
>
> List<String> prefixes = urisToPrefixes.get(nsURI);
> if (prefixes != null) ...
>
> seems not to be able to find the required prefix (the list is == null)
> and therefore the serialized file looks strange.
>
Strange in what way?
> What are we doing wrong?
>
I'm not sure. I think I need more details. Generally prefixes should
be demand created if they aren't already determined from having read a
previous serialization.
> many thanks
> Tiz
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Problems with XMLMap, XMLInfo and ExtendedMetaData [message #428379 is a reply to message #428373] |
Wed, 18 March 2009 18:19 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000103040909080706060800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Tiz,
Comments below.
Tiziano Leidi wrote:
> Hi Ed,
>
> please consider the following (simplified) example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <com.example.model1:thing1 xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:com.example.model1="http://www.ourweb.org/model1"
> xmi:id="_jfgKQBPNEd6K4_2CNujSUw"/>
>
> the resource may further contain an important amount of other EObject
> (root elements too) coming from model1 or model2 or even GMF Diagrams
> and nodes and ...
>
> We need to convert it e.g. to:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <com.example.model2:thing2 xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:com.example.model2="http://www.ourweb.org/model2"
> xmi:id="_jfgKQBPNEd6K4_2CNujSUw"/>
>
> without affecting other stuff contained in the resource
> (like e.g. com.example.model1:thing3)
>
Note that unless you have xsi:type/xmi:type it won't matter. Do you?
>
>> You're only needing to correct certain classifiers?
>>
>
> Yes, ... mainly ... root classifiers should be converted from:
>
Being a root is a property of the instance not a property of the
classifier...
> com.example.model1:thing1
> to
> com.example.model2:thing2
> (wher model2 = model1 is a possible situation too).
> The conversion is done dynamically depending on the context and the
> user needs.
>
Are you actually seeing other uses of com.example.model1 in the nested
content?
> Changing the name thing1 -> thing2 is now not a problem any more by
> using ExtendedMetaData and overriding getName().
>
> Changing the namespace is however a different thing:
>
> How do we intercept in extendedmetadata that the namespace change
> opportunity for just the root object (e.g. thing1)
>
What if thing1 is nested? Is that not possible?
> We don't want to modify the namespace of all other contained
> classifier and fetures that could be inside the resource, but are
> correctly associated with model1 (like e.g. thing3)?
>
Generally in XMI serializations, nested things aren't qualified at all.
Only the xsi/xmi:type will refer to the classifiers directly...
>
>>> Furthermore we experience a strange behaviour: When overriding the
>>> method
>>> String getNamespace(EPackage ePackage);
>>> the code located in Class XMLHelperImpl at line 566:
>>>
>>> List<String> prefixes = urisToPrefixes.get(nsURI);
>>> if (prefixes != null) ...
>>>
>>> seems not to be able to find the required prefix (the list is == null)
>>> and therefore the serialized file looks strange.
>>>
>>>
>> Strange in what way?
>>
>>> What are we doing wrong?
>>>
>
> With our attempt we obtained following result:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <com.example.model1:thing2 xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:com.example.model1="http://www.ourweb.org/model2"
> xmi:id="_jfgKQBPNEd6K4_2CNujSUw"/>
>
> Which is half a solution from our point of view.
>
It will still get the prefix from the package. If you override
XMLHelpImpl, you have complete control over these types of things...
> the namespace changes but the prefix remains the same.
>
You could prime your specialized helper with addNSDeclaration.
> many thanks
> Tiz
>
--------------000103040909080706060800
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">
Tiz,<br>
<br>
Comments below.<br>
<br>
Tiziano Leidi wrote:
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">Hi Ed,
please consider the following (simplified) example:
<?xml version="1.0" encoding="UTF-8"?>
<com.example.model1:thing1 xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:com.example.model1=<a class="moz-txt-link-rfc2396E" href="http://www.ourweb.org/model1">"http://www.ourweb.org/model1"</a>
xmi:id="_jfgKQBPNEd6K4_2CNujSUw"/>
the resource may further contain an important amount of other EObject
(root elements too) coming from model1 or model2 or even GMF Diagrams
and nodes and ...
We need to convert it e.g. to:
<?xml version="1.0" encoding="UTF-8"?>
<com.example.model2:thing2 xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:com.example.model2=<a class="moz-txt-link-rfc2396E" href="http://www.ourweb.org/model2">"http://www.ourweb.org/model2"</a>
xmi:id="_jfgKQBPNEd6K4_2CNujSUw"/>
without affecting other stuff contained in the resource
(like e.g. com.example.model1:thing3)
</pre>
</blockquote>
Note that unless you have xsi:type/xmi:type it won't matter. Do you?<br>
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">You're only needing to correct certain classifiers?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, ... mainly ... root classifiers should be converted from:
</pre>
</blockquote>
Being a root is a property of the instance not a property of the
classifier...<br>
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">com.example.model1:thing1
to
com.example.model2:thing2
(wher model2 = model1 is a possible situation too).
The conversion is done dynamically depending on the context and the
user needs.
</pre>
</blockquote>
Are you actually seeing other uses of com.example.model1 in the nested
content?
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">
Changing the name thing1 -> thing2 is now not a problem any more by
using ExtendedMetaData and overriding getName().
Changing the namespace is however a different thing:
How do we intercept in extendedmetadata that the namespace change
opportunity for just the root object (e.g. thing1)
</pre>
</blockquote>
What if thing1 is nested? Is that not possible?<br>
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">We don't want to modify the namespace of all other contained
classifier and fetures that could be inside the resource, but are
correctly associated with model1 (like e.g. thing3)?
</pre>
</blockquote>
Generally in XMI serializations, nested things aren't qualified at
all. Only the xsi/xmi:type will refer to the classifiers directly...<br>
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Furthermore we experience a strange behaviour: When overriding the
method
String getNamespace(EPackage ePackage);
the code located in Class XMLHelperImpl at line 566:
List<String> prefixes = urisToPrefixes.get(nsURI);
if (prefixes != null) ...
seems not to be able to find the required prefix (the list is == null)
and therefore the serialized file looks strange.
</pre>
</blockquote>
<pre wrap="">Strange in what way?
</pre>
<blockquote type="cite">
<pre wrap="">What are we doing wrong?
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
With our attempt we obtained following result:
<?xml version="1.0" encoding="UTF-8"?>
<com.example.model1:thing2 xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:com.example.model1=<a class="moz-txt-link-rfc2396E" href="http://www.ourweb.org/model2">"http://www.ourweb.org/model2"</a>
xmi:id="_jfgKQBPNEd6K4_2CNujSUw"/>
Which is half a solution from our point of view.
</pre>
</blockquote>
It will still get the prefix from the package. If you override
XMLHelpImpl, you have complete control over these types of things...<br>
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">the namespace changes but the prefix remains the same.
</pre>
</blockquote>
You could prime your specialized helper with addNSDeclaration.<br>
<blockquote cite="mid:k232s4dku4abas78o6mkup25n3tptsptnk@4ax.com"
type="cite">
<pre wrap="">
many thanks
Tiz
</pre>
</blockquote>
</body>
</html>
--------------000103040909080706060800--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 14:18:07 GMT 2024
Powered by FUDForum. Page generated in 0.03368 seconds |
] 
Search
Help
Register
Login
Home
