Home » Modeling » EMF » Re: ECORE 2 XML Schema and back
| Re: ECORE 2 XML Schema and back [message #427676] |
Wed, 25 February 2009 21:02  |
 Renat Zubairov
Messages: 30
Registered: July 2009 |
Member |
|
|
Thans Ed for reply. I tried it on Extended library model. I transformed the
ecore to XSD and then generated ecore again from the XSD I've got before.
Then I turn it to XSD again and... All element definitions that were
mentoned in XSD are gone. Also transitive, derived and volatile attributes
have not survived the round trip in the ECORE. Also one attribute
(people:EFeatureMapEntry) didn't survived either.
But most interesting part is that all types were changing the namespace, see
the example here:
http://screencast.com/t/zoa3wMLujP2
They used to be defined in http://www.eclipse.org/... Ecore.ecore... but
after roundtrip they became /plugin/org..../Ecore.ecore...
Renat
On 25.02.09 16:15, in article go3nb0$qlu$2@build.eclipse.org, "Ed Merks"
<Ed.Merks@gmail.com> wrote:
> Renat,
>
> Yes, the idea is that Ecore -> XSD -> Ecore should be a round trip.
> It's possible that I've overlooked something, but if so, you can report
> it and I'll fix it. This is really an EMF question, not an EMFT question...
>
>
> Renat Zubairov wrote:
>> Hi all,
>>
>> I generated XML Schema from ECORE using "Generator -> Export model..."
>> option. And the generated Schema contains attributes in ecore namespace "
>> http://www.eclipse.org/emf/2002/Ecore". May I assume that this kind of
>> transformation is reversible, so that next time I will generate ECORE back
>> from this schema I will get exactly the same ECORE model? Is there any
>> limitations on that?
>>
>> Thanks!
>>
>> Renat
>>
>>
|
|
|
| Re: ECORE 2 XML Schema and back [message #427677 is a reply to message #427676] |
Wed, 25 February 2009 21:36  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030605000809090204080409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Renat,
Comments below.
Renat Zubairov wrote:
> Thans Ed for reply. I tried it on Extended library model. I transformed the
> ecore to XSD and then generated ecore again from the XSD I've got before.
> Then I turn it to XSD again and... All element definitions that were
> mentoned in XSD are gone.
I didn't say XSD -> Ecore -> XSD is a round trip.
> Also transitive, derived and volatile attributes
> have not survived the round trip in the ECORE. Also one attribute
> (people:EFeatureMapEntry) didn't survived either.
>
Yes, I think you're right about the transient thing. They're really not
supposed to be in the XSD given they are transient and hence not
serialized...
> But most interesting part is that all types were changing the namespace, see
> the example here:
>
> http://screencast.com/t/zoa3wMLujP2
>
> They used to be defined in http://www.eclipse.org/... Ecore.ecore... but
> after roundtrip they became /plugin/org..../Ecore.ecore...
>
The Ecore model is kind of special so these two versions of it are
effectively equivalent when it comes to their use as data types.
> Renat
>
>
> On 25.02.09 16:15, in article go3nb0$qlu$2@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
>
>
>> Renat,
>>
>> Yes, the idea is that Ecore -> XSD -> Ecore should be a round trip.
>> It's possible that I've overlooked something, but if so, you can report
>> it and I'll fix it. This is really an EMF question, not an EMFT question...
>>
>>
>> Renat Zubairov wrote:
>>
>>> Hi all,
>>>
>>> I generated XML Schema from ECORE using "Generator -> Export model..."
>>> option. And the generated Schema contains attributes in ecore namespace "
>>> http://www.eclipse.org/emf/2002/Ecore". May I assume that this kind of
>>> transformation is reversible, so that next time I will generate ECORE back
>>> from this schema I will get exactly the same ECORE model? Is there any
>>> limitations on that?
>>>
>>> Thanks!
>>>
>>> Renat
>>>
>>>
>>>
>
>
--------------030605000809090204080409
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">
Renat,<br>
<br>
Comments below.<br>
<br>
Renat Zubairov wrote:
<blockquote cite="mid:C5CB705B.1AAD%25renat.zubairov@sopera.de"
type="cite">
<pre wrap="">Thans Ed for reply. I tried it on Extended library model. I transformed the
ecore to XSD and then generated ecore again from the XSD I've got before.
Then I turn it to XSD again and... All element definitions that were
mentoned in XSD are gone. </pre>
</blockquote>
I didn't say XSD -> Ecore -> XSD is a round trip.<br>
<blockquote cite="mid:C5CB705B.1AAD%25renat.zubairov@sopera.de"
type="cite">
<pre wrap="">Also transitive, derived and volatile attributes
have not survived the round trip in the ECORE. Also one attribute
(people:EFeatureMapEntry) didn't survived either.
</pre>
</blockquote>
Yes, I think you're right about the transient thing. They're really
not supposed to be in the XSD given they are transient and hence not
serialized...<br>
<blockquote cite="mid:C5CB705B.1AAD%25renat.zubairov@sopera.de"
type="cite">
<pre wrap="">But most interesting part is that all types were changing the namespace, see
the example here:
<a class="moz-txt-link-freetext" href="http://screencast.com/t/zoa3wMLujP2">http://screencast.com/t/zoa3wMLujP2</a>
They used to be defined in <a class="moz-txt-link-freetext" href="http://www.eclipse.org/">http://www.eclipse.org/</a>... Ecore.ecore... but
after roundtrip they became /plugin/org..../Ecore.ecore...
</pre>
</blockquote>
The Ecore model is kind of special so these two versions of it are
effectively equivalent when it comes to their use as data types.<br>
<blockquote cite="mid:C5CB705B.1AAD%25renat.zubairov@sopera.de"
type="cite">
<pre wrap="">
Renat
On 25.02.09 16:15, in article <a class="moz-txt-link-abbreviated" href="mailto:go3nb0$qlu$2@build.eclipse.org">go3nb0$qlu$2@build.eclipse.org</a>, "Ed Merks"
<a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Renat,
Yes, the idea is that Ecore -> XSD -> Ecore should be a round trip.
It's possible that I've overlooked something, but if so, you can report
it and I'll fix it. This is really an EMF question, not an EMFT question...
Renat Zubairov wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
I generated XML Schema from ECORE using "Generator -> Export model..."
option. And the generated Schema contains attributes in ecore namespace <a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/Ecore">"
http://www.eclipse.org/emf/2002/Ecore"</a>. May I assume that this kind of
transformation is reversible, so that next time I will generate ECORE back
from this schema I will get exactly the same ECORE model? Is there any
limitations on that?
Thanks!
Renat
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------030605000809090204080409--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: ECORE 2 XML Schema and back [message #427687 is a reply to message #427681] |
Thu, 26 February 2009 13:02 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060806010507020009020408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Renat,
Comments below.
Renat Zubairov wrote:
> Hi,
>
> Sorry I didn't expressed my self right, it's not transitive, derived
> and volatile attributes are gone, attributes are still there, but
> these 3 properties of the attributes were not persistent in the
> serialized XML Schema hence weren't restored.
>
> So I have following scenario:
>
> ECORE_1 -> XML Schema -> ECORE_2
>
> In ECORE_2 transitive, derived and volatile properties of the
> attributes were not restored to the values from ECORE_1.
>
> Also if generation process reversible, with any transformation ECORE_1
> -> XMLSchema_1 -> ECORE_2 -> XMLSchema_2 -> ECORE_3 we could assume
> that ECORE_1 === ECORE_2 === ECORE_3 hence XMLSchema_1 should be
> equivalent to XMLSchema_2.
Which version of EMF are you using? There should be things like
ecore:derive="true" I think. But of course it's possible I overlooked
something. If I have, create a test case and open a bugzilla with the
issue.
>
> The background of my question is: I am thinking about using ECORE for
> service interface definition in SOA/SCA applications, more or less
> what project Servus was doing, however IMO reinventing the new form of
> service description is not very attractive therefore if we could just
> serialize ECORE to XML Schema we could use this XML Schema inside the
> WSDL files.
Yes, that seemed appealing to me as well.
> Advantages are that such WSDL files will be still understandable by
> non-EMF-aware clients (e.g. .NET, PHP, etc) however EMF-aware clients
> would be able to employ all advantages of EMF-based modelling. This
> will only work out if ECORE serialized into XML Schema will be
> equivalent to the original ECORE.
Yes, that's exactly the idea. That you can exchange Ecore models as
valid conforming XML Schemas...
>
> Any suggestions? May be I missed something?
I think it's a good idea. I'll try to fix any problems you encounter.
Of course there are limitations to this approach. For example, XML
Schema simply doesn't support multiple inheritance and while we can
round trip the Ecore model that includes this, the schema won't accurate
describe actual serializations. That's effectively a problem that can't
be solved...
>
> Renat
>
> On 25.02.09 22:36, in article go4dki$aon$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
> Renat,
>
> Comments below.
>
> Renat Zubairov wrote:
>
>
> Thans Ed for reply. I tried it on Extended library model. I
> transformed the
> ecore to XSD and then generated ecore again from the XSD I've
> got before.
> Then I turn it to XSD again and... All element definitions
> that were
> mentoned in XSD are gone.
>
> I didn't say XSD -> Ecore -> XSD is a round trip.
>
>
> Also transitive, derived and volatile attributes
> have not survived the round trip in the ECORE. Also one attribute
> (people:EFeatureMapEntry) didn't survived either.
>
>
> Yes, I think you're right about the transient thing. They're
> really not supposed to be in the XSD given they are transient and
> hence not serialized...
>
>
> But most interesting part is that all types were changing the
> namespace, see
> the example here:
>
> http://screencast.com/t/zoa3wMLujP2
>
> They used to be defined in http://www.eclipse.org/...
> Ecore.ecore... but
> after roundtrip they became /plugin/org..../Ecore.ecore...
>
> The Ecore model is kind of special so these two versions of it
> are effectively equivalent when it comes to their use as data
> types.
>
>
>
> Renat
>
>
> On 25.02.09 16:15, in article
> go3nb0$qlu$2@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> <mailto:Ed.Merks@gmail.com> wrote:
>
>
>
>
>
> Renat,
>
> Yes, the idea is that Ecore -> XSD -> Ecore should be
> a round trip.
> It's possible that I've overlooked something, but if
> so, you can report
> it and I'll fix it. This is really an EMF question,
> not an EMFT question...
>
>
> Renat Zubairov wrote:
>
>
>
>
> Hi all,
>
> I generated XML Schema from ECORE using "Generator
> -> Export model..."
> option. And the generated Schema contains
> attributes in ecore namespace "
> http://www.eclipse.org/emf/2002/Ecore"
> <http://www.eclipse.org/emf/2002/Ecore> . May I
> assume that this kind of
> transformation is reversible, so that next time I
> will generate ECORE back
> from this schema I will get exactly the same ECORE
> model? Is there any
> limitations on that?
>
> Thanks!
>
> Renat
>
>
>
>
>
>
>
>
>
>
>
--------------060806010507020009020408
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">
Renat,<br>
<br>
Comments below.<br>
<br>
Renat Zubairov wrote:
<blockquote cite="mid:C5CC0ABD.1B0B%25renat.zubairov@sopera.de"
type="cite">
<title>Re: ECORE 2 XML Schema and back</title>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hi,<br>
<br>
Sorry I didn’t expressed my self right, it’s not transitive, derived
and volatile attributes are gone, attributes are still there, but these
3 properties of the attributes were not persistent in the serialized
XML Schema hence weren’t restored.<br>
<br>
So I have following scenario:<br>
<br>
ECORE_1 -> XML Schema -> ECORE_2<br>
<br>
In ECORE_2 transitive, derived and volatile properties of the
attributes were not restored to the values from ECORE_1. <br>
<br>
Also if generation process reversible, with any transformation ECORE_1
-> XMLSchema_1 -> ECORE_2 -> XMLSchema_2 -> ECORE_3 we
could assume that ECORE_1 === ECORE_2 === ECORE_3 hence XMLSchema_1
should be equivalent to XMLSchema_2.<br>
</span></font></font></blockquote>
Which version of EMF are you using? There should be things like
ecore:derive="true" I think. But of course it's possible I overlooked
something. If I have, create a test case and open a bugzilla with the
issue.<br>
<blockquote cite="mid:C5CC0ABD.1B0B%25renat.zubairov@sopera.de"
type="cite"><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
The background of my question is: I am thinking about using ECORE for
service interface definition in SOA/SCA applications, more or less what
project Servus was doing, however IMO reinventing the new form of
service description is not very attractive therefore if we could just
serialize ECORE to XML Schema we could use this XML Schema inside the
WSDL files. </span></font></font></blockquote>
Yes, that seemed appealing to me as well.<br>
<blockquote cite="mid:C5CC0ABD.1B0B%25renat.zubairov@sopera.de"
type="cite"><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Advantages are that such WSDL files will be
still understandable by non-EMF-aware clients (e.g. .NET, PHP, etc)
however EMF-aware clients would be able to employ all advantages of
EMF-based modelling. This will only work out if ECORE serialized into
XML Schema will be equivalent to the original ECORE.<br>
</span></font></font></blockquote>
Yes, that's exactly the idea. That you can exchange Ecore models as
valid conforming XML Schemas...<br>
<blockquote cite="mid:C5CC0ABD.1B0B%25renat.zubairov@sopera.de"
type="cite"><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
Any suggestions? May be I missed something?<br>
</span></font></font></blockquote>
I think it's a good idea. I'll try to fix any problems you encounter.
Of course there are limitations to this approach. For example, XML
Schema simply doesn't support multiple inheritance and while we can
round trip the Ecore model that includes this, the schema won't
accurate describe actual serializations. That's effectively a problem
that can't be solved...<br>
<blockquote cite="mid:C5CC0ABD.1B0B%25renat.zubairov@sopera.de"
type="cite"><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
Renat <br>
<br>
On 25.02.09 22:36, in article <a class="moz-txt-link-abbreviated" href="mailto:go4dki$aon$1@build.eclipse.org">go4dki$aon$1@build.eclipse.org</a>, "Ed
Merks" <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> wrote:<br>
<br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Renat,<br>
<br>
Comments below.<br>
<br>
Renat Zubairov wrote: <br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
Thans Ed for reply. I tried it on Extended library model. I transformed
the<br>
ecore to XSD and then generated ecore again from the XSD I've got
before.<br>
Then I turn it to XSD again and... All element definitions that were<br>
mentoned in XSD are gone. <br>
</span></font></font></blockquote>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">I didn't say XSD -> Ecore -> XSD is a
round trip.<br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
Also transitive, derived and volatile attributes<br>
have not survived the round trip in the ECORE. Also one attribute<br>
(people:EFeatureMapEntry) didn't survived either.<br>
<br>
</span></font></font></blockquote>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Yes, I think you're right about the transient
thing. They're really not supposed to be in the XSD given they are
transient and hence not serialized...<br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
But most interesting part is that all types were changing the
namespace, see<br>
the example here:<br>
<br>
<a moz-do-not-send="true"
href="http://screencast.com/t/zoa3wMLujP2">http://screencast.com/t/zoa3wMLujP2</a><br>
<br>
They used to be defined in <a moz-do-not-send="true"
href="http://www.eclipse.org/...">http://www.eclipse.org/...</a>
Ecore.ecore... but<br>
after roundtrip they became /plugin/org..../Ecore.ecore...<br>
<br>
The Ecore model is kind of special so these two versions of it are
effectively equivalent when it comes to their use as data types.<br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
<br>
Renat<br>
<br>
<br>
On 25.02.09 16:15, in article <a class="moz-txt-link-abbreviated" href="mailto:go3nb0$qlu$2@build.eclipse.org">go3nb0$qlu$2@build.eclipse.org</a>, "Ed Merks"<br>
<a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> <a moz-do-not-send="true"
href="mailto:Ed.Merks@gmail.com"><mailto:Ed.Merks@gmail.com></a>
wrote:<br>
<br>
<br>
<br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
Renat,<br>
<br>
Yes, the idea is that Ecore -> XSD -> Ecore should be a round
trip.<br>
It's possible that I've overlooked something, but if so, you can report<br>
it and I'll fix it. This is really an EMF question, not an EMFT
question...<br>
<br>
<br>
Renat Zubairov wrote:<br>
<br>
<br>
</span></font></font>
<blockquote><font size="4"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
Hi all,<br>
<br>
I generated XML Schema from ECORE using "Generator -> Export
model..."<br>
option. And the generated Schema contains attributes in ecore namespace
"<br>
<a moz-do-not-send="true"
href="http://www.eclipse.org/emf/2002/Ecore">http://www.eclipse.org/emf/2002/Ecore</a>"
<a moz-do-not-send="true"
href="http://www.eclipse.org/emf/2002/Ecore"><http://www.eclipse.org/emf/2002/Ecore></a>
.. May I assume that this kind of<br>
transformation is reversible, so that next time I will generate ECORE
back<br>
from this schema I will get exactly the same ECORE model? Is there any<br>
limitations on that?<br>
<br>
Thanks!<br>
<br>
Renat<br>
<br>
<br>
<br>
<br>
<br>
</span></font></font></blockquote>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> <br>
<br>
<br>
</span></font></font></blockquote>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
</span></font></font></blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------060806010507020009020408--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 12:49:56 GMT 2024
Powered by FUDForum. Page generated in 0.03125 seconds |
] 
Search
Help
Register
Login
Home
