Home » Modeling » EMF » [EMF] Some questions to Ecore and serialization
| [EMF] Some questions to Ecore and serialization [message #542114] |
Wed, 23 June 2010 21:27  |
 Oliver
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Hi,
some questions...
Ecore:
When derived is set then the getter and setter is generated too. The
getter have to customized by the user, ok, but why is a setter generated?
When derived is set and transient is not set would the feature
serialized and get ignored when it is deserialized?
In a MOF view, Ecore is a meta-metamodel which can used to define
metamodels like statemachines (EClasses would be State, Transition etc.)
or ERM (EClasses would be Entity, Relationship etc.). UML, the best
example for metamodels is defined with Ecore (UML2.0 project). So this
metamodels can used to model aspects of a software like a statemechine
for a cd player or an an entity relation model for a webshop. And on the
underlying layer, a concrete customer 'smith' is an instance of a
customer entity.
Why are the examples for EMF/Ecore are library and purchase order? In my
opinion this two examples are not metamodels -- they are models. I think
Ecore should described with statemachines.
Serialization:
We have a custom xml-format like
<?xml version="1.0" encoding="UTF-8"?>
<SRC-File name="subjects">
<RTR-Subject name="mySubject" businessGroupReference="../test">
</RTR-Subject>
<RTR-BusinessGroup name="test">
</RTR-BusinessGroup>
</SRC-File>
So with ExtendedMetaData there was no problem to define the xml tag
names like "SRC-File" for the EClass "file". But the problems are:
- how can avoid the namespaces and xmi:version etc. ?
- the path schema to define references like "../test" differs from the
eURIFragmentSegment of BasicEObjectImpl
What can I do to bring our path schema to EMF? Like a pre listener of
XML that converts our path schema to EMF schema on reading the xml file.
When a XMI file is generated, there are information about the xml schema
(the nsURI of an EPackage). If I understand it right, XMI defines
production rules to create a schema based on a metamodel that can used
to validate the content of a model that is described by the metamodel.
Has EMF an generator for this schemas?
ciao
Olli
|
|
|
| Re: [EMF] Some questions to Ecore and serialization [message #542305 is a reply to message #542114] |
Thu, 24 June 2010 13:43  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Oliver,
Comments below.
Oliver wrote:
> Hi,
>
> some questions...
>
> Ecore:
> When derived is set then the getter and setter is generated too. The
> getter have to customized by the user, ok, but why is a setter generated?
If you don't want a setter, you'd set changeable to false.
>
> When derived is set and transient is not set would the feature
> serialized and get ignored when it is deserialized?
Anything that's in the serialization will be deserialized.
>
> In a MOF view, Ecore is a meta-metamodel which can used to define
> metamodels like statemachines (EClasses would be State, Transition
> etc.) or ERM (EClasses would be Entity, Relationship etc.). UML, the
> best example for metamodels is defined with Ecore (UML2.0 project). So
> this metamodels can used to model aspects of a software like a
> statemechine for a cd player or an an entity relation model for a
> webshop. And on the underlying layer, a concrete customer 'smith' is
> an instance of a customer entity.
> Why are the examples for EMF/Ecore are library and purchase order?
platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore is an instance,
so Ecore is an instance of a model, a model, a meta model, a meta meta
model and any number of metas you care to insert.
> In my opinion this two examples are not metamodels -- they are models.
Indeed. Ecore describes those too.
> I think Ecore should described with statemachines.
Ecore describes itself. There's no need for state machines.
>
> Serialization:
> We have a custom xml-format like
> <?xml version="1.0" encoding="UTF-8"?>
> <SRC-File name="subjects">
> <RTR-Subject name="mySubject" businessGroupReference="../test">
> </RTR-Subject>
> <RTR-BusinessGroup name="test">
> </RTR-BusinessGroup>
> </SRC-File>
> So with ExtendedMetaData there was no problem to define the xml tag
> names like "SRC-File" for the EClass "file". But the problems are:
> - how can avoid the namespaces and xmi:version etc. ?
Have a look a generating a model from an XML Schema without a target
namespace.
> - the path schema to define references like "../test" differs from the
> eURIFragmentSegment of BasicEObjectImpl
> What can I do to bring our path schema to EMF? Like a pre listener of
> XML that converts our path schema to EMF schema on reading the xml file.
You'll have to look closely at how the serializer
(XMLSaveImpl.saveElementReference) and the deserializer
(XMLHandler.setValueFromId) do their job right now.
>
> When a XMI file is generated, there are information about the xml
> schema (the nsURI of an EPackage). If I understand it right, XMI
> defines production rules to create a schema based on a metamodel that
> can used to validate the content of a model that is described by the
> metamodel. Has EMF an generator for this schemas?
That schema is called Ecore. The library and purchase order are examples.
>
> ciao
> Olli
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] Some questions to Ecore and serialization [message #542441 is a reply to message #542305] |
Thu, 24 June 2010 20:39 |
Oliver
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Thanks for quick answer!
Comments below.
Ed Merks schrieb:
> Oliver,
>
> Comments below.
>
>
> Oliver wrote:
>> Hi,
>>
>> some questions...
>>
>> Ecore:
>> When derived is set then the getter and setter is generated too. The
>> getter have to customized by the user, ok, but why is a setter generated?
> If you don't want a setter, you'd set changeable to false.
Yes, I know. The question is makes it sense to set derived without
unsetting changeable? In my opinion not, so I think there is a
constraint required in the EcoreValidator.
>>
>> When derived is set and transient is not set would the feature
>> serialized and get ignored when it is deserialized?
> Anything that's in the serialization will be deserialized.
That EStructuralFeatrures like "isMany" of EReference would be
serialized is ok, but do you think that it makes sense that the
deserializer set "isMany" from outside? If changeable is unset (i.e. no
setter is generated) and the deserializer would deserialize anything it
would crash.
>>
>> In a MOF view, Ecore is a meta-metamodel which can used to define
>> metamodels like statemachines (EClasses would be State, Transition
>> etc.) or ERM (EClasses would be Entity, Relationship etc.). UML, the
>> best example for metamodels is defined with Ecore (UML2.0 project). So
>> this metamodels can used to model aspects of a software like a
>> statemechine for a cd player or an an entity relation model for a
>> webshop. And on the underlying layer, a concrete customer 'smith' is
>> an instance of a customer entity.
>> Why are the examples for EMF/Ecore are library and purchase order?
> platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore is an instance,
> so Ecore is an instance of a model, a model, a meta model, a meta meta
> model and any number of metas you care to insert.
Oh no, so confusing stuff :)
M3: Meta-Metamodels describes Meta-Models of layer M2 and are self described
M2: Meta-Models describes models of layer M1
M1: Models describes instances of layer M0
M0: Instances are the concrete datasets
Applied to Ecore:
M3: Ecore is "isomorphic" to Essential MOF (EMOF). EMOF is described in
the MOF specification as a meta-metamodel so Ecore is a meta-metamodel
too. Also Ecore is self describing because we can see in Ecore.ecore for
example there is an EClass "EStructuralFeature".
M2: Ecore is described with Ecore we have seen in Ecore.ecore so Ecore
is a metamodel too.
M1: Why should Ecore be a model?
M0: Why should Ecore be a instance?
And for a academic M4 meta-meta-metamodel: Ecore can describe some other
meta-metamodel like XML and MOF. Comfirms this to your opinion?
(I know that Ecore is to designed pragmatically, but for dissertations
Ecore should described in an academic way too)
>> In my opinion this two examples are not metamodels -- they are models.
> Indeed. Ecore describes those too.
>> I think Ecore should described with statemachines.
> Ecore describes itself. There's no need for state machines.
Sorry, my english is terrible. Assuming that Ecore is mainly designed
for M3 the examples to get familiar with Ecore should metamodels like a
statemachine or a ERM and not models like tha library example. But this
is my understanding of model driven software development (MDSD) and you
have many years more experience with it. By the way, what's your
favourite literature for the MDSD topic?
>>
>> Serialization:
>> We have a custom xml-format like
>> <?xml version="1.0" encoding="UTF-8"?>
>> <SRC-File name="subjects">
>> <RTR-Subject name="mySubject" businessGroupReference="../test">
>> </RTR-Subject>
>> <RTR-BusinessGroup name="test">
>> </RTR-BusinessGroup>
>> </SRC-File>
>> So with ExtendedMetaData there was no problem to define the xml tag
>> names like "SRC-File" for the EClass "file". But the problems are:
>> - how can avoid the namespaces and xmi:version etc. ?
> Have a look a generating a model from an XML Schema without a target
> namespace.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/entity"
xmlns:entity="http://www.example.org/entity"
elementFormDefault="qualified">
<complexType name="entityType">
<choice>
<element ref="entity:property" minOccurs="0"
maxOccurs="unbounded">
</element>
</choice>
<attribute name="name" type="string" use="required"></attribute>
</complexType>
<complexType name="propertyType">
<attribute name="name" type="string" use="required"></attribute>
<attribute name="type" type="string" use="required"></attribute>
</complexType>
<element name="entity" type="entity:entityType"></element>
<element name="property" type="entity:propertyType"></element>
</schema>
Without the targetNamespace attribute EMF is unable to create a genmodel
for it. Do you mean this attribute or something else?
>> - the path schema to define references like "../test" differs from the
>> eURIFragmentSegment of BasicEObjectImpl
>> What can I do to bring our path schema to EMF? Like a pre listener of
>> XML that converts our path schema to EMF schema on reading the xml file.
> You'll have to look closely at how the serializer
> (XMLSaveImpl.saveElementReference) and the deserializer
> (XMLHandler.setValueFromId) do their job right now.
Ok, I will look closer. Thanks!
>>
>> When a XMI file is generated, there are information about the xml
>> schema (the nsURI of an EPackage). If I understand it right, XMI
>> defines production rules to create a schema based on a metamodel that
>> can used to validate the content of a model that is described by the
>> metamodel. Has EMF an generator for this schemas?
> That schema is called Ecore. The library and purchase order are examples.
Ok, I've seen EcoreXMI.xsd for Ecore as a metamodel :) But would a
LibraryXMI.xsd and a PurchaseOrderXMI.xsd make sense for you? I think a
XML parser can check with it if a model (e.g. a concrete library) in a
XMI file would (structural) correct. That's one of the benefits of XMI I
think. So LibraryXMI.xsd should generated.
>>
>> ciao
>> Olli
|
|
|
| Re: [EMF] Some questions to Ecore and serialization [message #542445 is a reply to message #542441] |
Thu, 24 June 2010 21:07 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Oliver,
Comments below.
Oliver wrote:
> Thanks for quick answer!
>
> Comments below.
>
> Ed Merks schrieb:
>> Oliver,
>>
>> Comments below.
>>
>>
>> Oliver wrote:
>>> Hi,
>>>
>>> some questions...
>>>
>>> Ecore:
>>> When derived is set then the getter and setter is generated too. The
>>> getter have to customized by the user, ok, but why is a setter
>>> generated?
>> If you don't want a setter, you'd set changeable to false.
> Yes, I know. The question is makes it sense to set derived without
> unsetting changeable? In my opinion not, so I think there is a
> constraint required in the EcoreValidator.
The XSD model has a great many derived features. It caches most of them
in the model instances using the setters.
>
>>>
>>> When derived is set and transient is not set would the feature
>>> serialized and get ignored when it is deserialized?
>> Anything that's in the serialization will be deserialized.
> That EStructuralFeatrures like "isMany" of EReference would be
> serialized is ok,
All non-transient features will be serialized, regardless of their
multiplicity so I'm not sure why you're paying specific attention to the
multiplicity in this discussion about serialization.
> but do you think that it makes sense that the deserializer set
> "isMany" from outside?
I totally don't follow the question.
> If changeable is unset (i.e. no setter is generated) and the
> deserializer would deserialize anything it would crash.
Yes, it will fail. Just as it would if you try to deserialize features
that don't exist. You just get a different message.
>
>>>
>>> In a MOF view, Ecore is a meta-metamodel which can used to define
>>> metamodels like statemachines (EClasses would be State, Transition
>>> etc.) or ERM (EClasses would be Entity, Relationship etc.). UML, the
>>> best example for metamodels is defined with Ecore (UML2.0 project).
>>> So this metamodels can used to model aspects of a software like a
>>> statemechine for a cd player or an an entity relation model for a
>>> webshop. And on the underlying layer, a concrete customer 'smith'
>>> is an instance of a customer entity.
>>> Why are the examples for EMF/Ecore are library and purchase order?
>> platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore is an
>> instance, so Ecore is an instance of a model, a model, a meta model,
>> a meta meta model and any number of metas you care to insert.
> Oh no, so confusing stuff :)
> M3: Meta-Metamodels describes Meta-Models of layer M2 and are self
> described
> M2: Meta-Models describes models of layer M1
> M1: Models describes instances of layer M0
> M0: Instances are the concrete datasets
In my talk about the "Unbearable Stupidity of Modeling" I explain the
dismay I sink into when the dreaded M's show up in the newsgroup. I'm
adamant that no good ever comes from the discussion that follows. It's
typically long and tortuous, usually circular, and ultimately pointless.
>
> Applied to Ecore:
> M3: Ecore is "isomorphic" to Essential MOF (EMOF). EMOF is described
> in the MOF specification as a meta-metamodel so Ecore is a
> meta-metamodel too. Also Ecore is self describing because we can see
> in Ecore.ecore for example there is an EClass "EStructuralFeature".
> M2: Ecore is described with Ecore we have seen in Ecore.ecore so Ecore
> is a metamodel too.
> M1: Why should Ecore be a model?
> M0: Why should Ecore be a instance?
> And for a academic M4 meta-meta-metamodel: Ecore can describe some
> other meta-metamodel like XML and MOF. Comfirms this to your opinion?
No, the serialized instance in
platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore is definitely
an instance. I can edit it just like I can edit Library.ecore. It's
definite an instance of Ecore so there definitely needs to be an Ecore
at the M1 level.
>
> (I know that Ecore is to designed pragmatically, but for dissertations
> Ecore should described in an academic way too)
I could live without that. :-P The common mistake is to believe that
these levels of meta-ness are absolute. They're not.
>
>
>>> In my opinion this two examples are not metamodels -- they are models.
>> Indeed. Ecore describes those too.
>>> I think Ecore should described with statemachines.
>> Ecore describes itself. There's no need for state machines.
> Sorry, my english is terrible. Assuming that Ecore is mainly designed
> for M3 the examples to get familiar with Ecore should metamodels like
> a statemachine or a ERM and not models like tha library example.
Generally people learn best from simple examples.
> But this is my understanding of model driven software development
> (MDSD) and you have many years more experience with it. By the way,
> what's your favourite literature for the MDSD topic?
The EMF book of course. :-P
>
>
>>>
>>> Serialization:
>>> We have a custom xml-format like
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <SRC-File name="subjects">
>>> <RTR-Subject name="mySubject" businessGroupReference="../test">
>>> </RTR-Subject>
>>> <RTR-BusinessGroup name="test">
>>> </RTR-BusinessGroup>
>>> </SRC-File>
>>> So with ExtendedMetaData there was no problem to define the xml tag
>>> names like "SRC-File" for the EClass "file". But the problems are:
>>> - how can avoid the namespaces and xmi:version etc. ?
>> Have a look a generating a model from an XML Schema without a target
>> namespace.
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://www.example.org/entity"
> xmlns:entity="http://www.example.org/entity"
> elementFormDefault="qualified">
> <complexType name="entityType">
> <choice>
> <element ref="entity:property" minOccurs="0"
> maxOccurs="unbounded">
> </element>
> </choice>
> <attribute name="name" type="string" use="required"></attribute>
> </complexType>
>
> <complexType name="propertyType">
> <attribute name="name" type="string" use="required"></attribute>
> <attribute name="type" type="string" use="required"></attribute>
> </complexType>
>
> <element name="entity" type="entity:entityType"></element>
> <element name="property" type="entity:propertyType"></element>
> </schema>
> Without the targetNamespace attribute EMF is unable to create a
> genmodel for it. Do you mean this attribute or something else?
>
>>> - the path schema to define references like "../test" differs from
>>> the eURIFragmentSegment of BasicEObjectImpl
>>> What can I do to bring our path schema to EMF? Like a pre listener
>>> of XML that converts our path schema to EMF schema on reading the
>>> xml file.
>> You'll have to look closely at how the serializer
>> (XMLSaveImpl.saveElementReference) and the deserializer
>> (XMLHandler.setValueFromId) do their job right now.
> Ok, I will look closer. Thanks!
>>>
>>> When a XMI file is generated, there are information about the xml
>>> schema (the nsURI of an EPackage). If I understand it right, XMI
>>> defines production rules to create a schema based on a metamodel
>>> that can used to validate the content of a model that is described
>>> by the metamodel. Has EMF an generator for this schemas?
>> That schema is called Ecore. The library and purchase order are
>> examples.
> Ok, I've seen EcoreXMI.xsd for Ecore as a metamodel :) But would a
> LibraryXMI.xsd and a PurchaseOrderXMI.xsd make sense for you?
Yes, we can produce those when someone wants that. Unfortunately XMI
serializations aren't well described by XML Schemas so such schemas are
pretty much pointless noise.
> I think a XML parser can check with it if a model (e.g. a concrete
> library) in a XMI file would (structural) correct. That's one of the
> benefits of XMI I think. So LibraryXMI.xsd should generated.
EMF uses Ecore directly for this purpose.
>
>>>
>>> ciao
>>> Olli
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] Some questions to Ecore and serialization [message #542452 is a reply to message #542441] |
Thu, 24 June 2010 21:37 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 24.06.10 22.39, Oliver wrote:
>
> Oh no, so confusing stuff :)
> M3: Meta-Metamodels describes Meta-Models of layer M2 and are self
> described
> M2: Meta-Models describes models of layer M1
> M1: Models describes instances of layer M0
> M0: Instances are the concrete datasets
When I lecture this to my students, I try to focus on one pair of levels
at a time. E.g. you have the library concept in the model and library
instances, the former being one level above the latter. When we come to
DSLs it's the same: you have the state concept and state instances. Only
two levels. You can imagine situations when you need more levels, like
if you model languages like Ecore and UML, which itself can model
concepts. But you very seldom have to focus on more than two levels at a
time. I think that's Ed's message: There's no need to make it difficult
for yourself by thinking about more than two levels at a time: model and
instance.
An analogy is the OSI network stack, with all it's layers. You go nuts
if you try to imagine what happens at all levels of the stack at once.
But why do it, when you usually need to see only one.
> (I know that Ecore is to designed pragmatically, but for dissertations
> Ecore should described in an academic way too)
He, he, that's because academics (like me) like to show off by show they
can manage many meta-levels ;-)
Hallvard
|
|
|
| Re: [EMF] Some questions to Ecore and serialization [message #542586 is a reply to message #542452] |
Fri, 25 June 2010 11:39 |
|
Dear Oliver,
I can suggest you two readings about the "meta" stuff.
On the Unification Power of Models
@article{bézivin2005unification,
title={{On the unification power of models}},
author={B{\'e}zivin, J.},
journal={Software and Systems Modeling},
volume={4},
number={2},
pages={171--188},
year={2005},
publisher={Springer}
}
Model-based technology integration with the technical space concept
@conference{bézivin2005model,
title={{Model-based technology integration with the technical space concept}},
author={B{\'e}zivin, J. and Kurtev, I.},
booktitle={Metainformatics Symposium},
year={2005},
organization={Citeseer}
}
You can download the pdf online I think.
Hope it helps.
Ciao
Luca Berardinelli
|
|
|
| Re: [EMF] Some questions to Ecore and serialization [message #542667 is a reply to message #542452] |
Fri, 25 June 2010 14:45 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Exactly. There are models and there are instances of them. A model is
a meta model, if instances of that model can be further instantiated.
But if you ignore what the instances mean and what you can do with them,
then you only see models and instances. If thinking a lot about meta
results in the conclusion that Ecore shouldn't exist at the M0 and M1
levels, then reality has become lost in a cloud of meta.
Hallvard Trætteberg wrote:
> On 24.06.10 22.39, Oliver wrote:
>>
>> Oh no, so confusing stuff :)
>> M3: Meta-Metamodels describes Meta-Models of layer M2 and are self
>> described
>> M2: Meta-Models describes models of layer M1
>> M1: Models describes instances of layer M0
>> M0: Instances are the concrete datasets
>
> When I lecture this to my students, I try to focus on one pair of
> levels at a time. E.g. you have the library concept in the model and
> library instances, the former being one level above the latter. When
> we come to DSLs it's the same: you have the state concept and state
> instances. Only two levels. You can imagine situations when you need
> more levels, like if you model languages like Ecore and UML, which
> itself can model concepts. But you very seldom have to focus on more
> than two levels at a time. I think that's Ed's message: There's no
> need to make it difficult for yourself by thinking about more than two
> levels at a time: model and instance.
>
> An analogy is the OSI network stack, with all it's layers. You go nuts
> if you try to imagine what happens at all levels of the stack at once.
> But why do it, when you usually need to see only one.
>
>> (I know that Ecore is to designed pragmatically, but for dissertations
>> Ecore should described in an academic way too)
>
> He, he, that's because academics (like me) like to show off by show
> they can manage many meta-levels ;-)
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: [EMF] Some questions to Ecore and serialization [message #543277 is a reply to message #543251] |
Mon, 28 June 2010 21:48 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Oliver,
Comments below.
Oliver wrote:
> Thank you all for answer!
>
> Ed,
>
> I mean the "many" feature of an ETypedElement (Emfatic style):
> abstract class ETypedElement extends ENamedElement {
> // ...
> attr EInt upperBound = "1";
> readonly volatile transient derived attr EBoolean many; // <-----
> readonly volatile transient derived attr EBoolean required;
> // ...
> }
> When it would not declared as transient, it would be serialized in a
> .ecore file and by deserializing this attribute would set by the
> deserializer. I hope now the question makes sense of
> "should there a constraint to avoid derived = true and transient =
> false at the same time?".
I don't want to presuppose that such a thing is simple flat out wrong.
Someone might want it to be serialized to avoid an expensive
computation, or for information purposes. Who's to say.
>
> "Unbearable Stupidity of Modeling" was very funny at a working days
> morning :) "Meta what?" hihi
>
> And to the path-references: I think a simple XSLT would be the easiest
> way to get a proprietary XML conform too the XMLResource.
>
> Hallvard, yes, it might be possible that I focus too much of the
> metalevels. Previous "anything is an object" now "anything is a model"
> ok, ok, ok :)
>
> Luca, this is exactly what I was searching for. Thank you! Jean
> Bézivin have a big talent to teach complicated things in a simple way.
>
> ciao
> Olli
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 04:58:54 GMT 2024
Powered by FUDForum. Page generated in 0.03681 seconds |
] 
Search
Help
Register
Login
Home
