Eclipse Community Forums: EMF » De-serialization of extended eCore models

Home » Modeling » EMF » De-serialization of extended eCore models(Looking for steps to extend existing eCore model)

De-serialization of extended eCore models [message #658314]

Mon, 07 March 2011 15:33

Eclipse User

I am looking for advice on how to approach extending an existing eCore model to add an EAttribute to an EClass. Besides extending and generating my own model, what else is required so that the model will load?

Below is a psuedo representation of a serialized model as it currently is.

<uri1:parent
        xmlns:uri1="URI1"
        xmlns:xx="SomeTypeURI"
        xsi:noNamespaceSchema="URI1"
	...
	>

	<child id="A">
		<gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
	</child>
</parent>

I wish to add a new "myAttr" attribute to the "child" element such that I have:

<uri1:parent
	xmlns:uri1="URI1"
	xmlns:xx="SomeTypeURI"
	xsi:noNamespaceSchema="URI1"	
	...
	xmlns:uri2="MyModelURI"
	>

	<!-- Preferred option but doubt that this is possible -->
	<child id="A" myAttr="something">
		<gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
	</child>
	
	<!-- OR -->
	<child xsi:type="uri2:childSubclass" id="A" myAttr="something">
		<gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
	</child>	
		
	<!-- OR -->
	<uri2:childSubclass id="A" myAttr="something">
		<gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
	</uri2:childSubclass>
	
</parent>

All of my many attempts so far have failed to successfully load a model and I am not sure where the problem is. Either the child subclass does not load correctly, or the gchild value does not. I have not been successful in finding a post or set of posts that can assist me with the steps involved.

Many thanks in advance.

Re: De-serialization of extended eCore models [message #658329 is a reply to message #658314]

Mon, 07 March 2011 17:31

Eclipse User

JK,

Comments below.

JK wrote:
> I am looking for advice on how to approach extending an existing eCore
> model to add an EAttribute to an EClass. Besides extending and
> generating my own model, what else is required so that the model will
> load?
They'll both need to be registered in the package registry.
> Below is a psuedo representation of a serialized model as it currently
> is.
>
> <uri1:parent
> xmlns:uri1="URI1"
> xmlns:xx="SomeTypeURI"
> xsi:noNamespaceSchema="URI1"
> ...
> >
>
> <child id="A">
> <gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
> </child>
> </parent>
>
>
> I wish to add a new "myAttr" attribute to the "child" element such
> that I have:
>
>
> <uri1:parent
> xmlns:uri1="URI1"
> xmlns:xx="SomeTypeURI"
> xsi:noNamespaceSchema="URI1"
> ...
> xmlns:uri2="MyModelURI"
> >
>
> 
The subtype that supports myAttr needs to be explicitly given.
> <child id="A" myAttr="something">
> <gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
> </child>
>
> 
> <child xsi:type="uri2:childSubclass" id="A" myAttr="something">
> <gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
> </child>
So what goes wrong here?
>
> 
> <uri2:childSubclass id="A" myAttr="something">
Class names are not used as element names (except at the root of an XMI
serialization).
> <gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
> </uri2:childSubclass>
>
> </parent>
>
>
> All of my many attempts so far have failed to successfully load a
> model and I am not sure where the problem is. Either the child
> subclass does not load correctly, or the gchild value does not. I
> have not been successful in finding a post or set of posts that can
> assist me with the steps involved.
I don't really know what you've tried nor what's gone wrong. The use of
xsi:type should do the trick.
>
>
> Many thanks in advance.

Re: De-serialization of extended eCore models [message #658336 is a reply to message #658329]

Mon, 07 March 2011 18:47

Eclipse User

After your post assured me that the form below is how it needs to be, I went back and undid some things in code that I had tried in a (poor) attempt to get things to work. But now all is well.

	 <child xsi:type="uri2:childSubclass" id="A" myAttr="something">

Many thanks Ed.

Re: De-serialization of extended eCore models [message #658816 is a reply to message #658336]

Wed, 09 March 2011 17:14

Eclipse User

Hi Ed,

I have a related follow on question. I hadn't realized that my test file was a little different than the pseudo xml originally provided.

Why is it that the model will not load unless the namespace is provided on "gchild" element?

The following works:

...
	<child xsi:type="uri2:childSubclass" id="A" myAttr="something">
		<uri1:gchild xsi:type="xx:SomeType">SOMEVALUE</uri1:gchild>
	</child>
...

The following yields an exception during load (Caused by: org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'gchild' not found.):

...
	<child xsi:type="uri2:childSubclass" id="A" myAttr="something">
		<gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
	</child>
...

Thanks

Re: De-serialization of extended eCore models [message #658828 is a reply to message #658816]

Wed, 09 March 2011 17:36

Eclipse User

JK,

Comments below.

JK wrote:
> Hi Ed,
>
> I have a related follow on question. I hadn't realized that my test
> file was a little different than the pseudo xml originally provided.
>
> Why is it that the model will not load unless the namespace is
> provided on "gchild" element?
> The following works:
>
> ..
> <child xsi:type="uri2:childSubclass" id="A" myAttr="something">
> <uri1:gchild xsi:type="xx:SomeType">SOMEVALUE</uri1:gchild>
> </child>
> ..
My guess would be that gchild corresponds to a global element
declaration in our schema and those must be namespace qualified.
>
>
>
> The following yields an exception during load (Caused by:
> org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'gchild'
> not found.):
>
> ..
> <child xsi:type="uri2:childSubclass" id="A" myAttr="something">
> <gchild xsi:type="xx:SomeType">SOMEVALUE</gchild>
> </child>
This would be a local element declaration.
> ..
>
>
> Thanks

Re: De-serialization of extended eCore models [message #658831 is a reply to message #658828]

Wed, 09 March 2011 18:16

Eclipse User

> My guess would be that gchild corresponds to a global element
> declaration in our schema and those must be namespace qualified.

Thanks again Ed, and sorry for having to make you guess. I thought I was doing everyone a favour by simplifying my example.

"gchild" actually refers to an element named "value" in my "uri1" namespace and is an EReference to an EObject. The xsi:type on the gchild element refers to the EObject type.

Before subclassing "child", the model deserialized fine without the need for the namespace prefix, so I am not sure if your answer makes sense.

Re: De-serialization of extended eCore models [message #658838 is a reply to message #658831]

Wed, 09 March 2011 19:36

Eclipse User

JK,

Are these models derived from schemas? Can you show me the "gchild"
feature as it looks in the Ecore file?

JK wrote:
>> My guess would be that gchild corresponds to a global element
>> declaration in our schema and those must be namespace qualified.
>
> Thanks again Ed, and sorry for having to make you guess. I thought I
> was doing everyone a favour by simplifying my example.
>
> "gchild" actually refers to an element named "value" in my "uri1"
> namespace and is an EReference to an EObject. The xsi:type on the
> gchild element refers to the EObject type.
>
> Before subclassing "child", the model deserialized fine without the
> need for the namespace prefix, so I am not sure if your answer makes
> sense.
>
>
>

Re: De-serialization of extended eCore models [message #659034 is a reply to message #658838]

Thu, 10 March 2011 13:19

Eclipse User

The eCore models were handrolled, and did not come from schemas.

The following is the "gchild", or "value", feature as defined in the eCore model.

    <eStructuralFeatures xsi:type="ecore:EReference" name="value" lowerBound="1" eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject"
        containment="true">
      <eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
        <details key="kind" value="element"/>
        <details key="namespace" value="##targetNamespace"/>
      </eAnnotations>
    </eStructuralFeatures>

Re: De-serialization of extended eCore models [message #659047 is a reply to message #659034]

Thu, 10 March 2011 14:24

Eclipse User

JK,

So you've hand rolled an annotation that says "this feature should be
serialized as an element that's namespace qualified with the containing
package's namespace". Get rid of <details key="namespace"
value="##targetNamespace"/> if you don't want qualification.

JK wrote:
> The eCore models were handrolled, and did not come from schemas.
>
> The following is the "gchild", or "value", feature as defined in the
> eCore model.
>
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="value"
> lowerBound="1" eType="ecore:EClass
> http://www.eclipse.org/emf/2002/Ecore#//EObject"
> containment="true">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="element"/>
> <details key="namespace" value="##targetNamespace"/>
> </eAnnotations>
> </eStructuralFeatures>
>

Re: De-serialization of extended eCore models [message #659854 is a reply to message #659047]

Tue, 15 March 2011 15:20

Eclipse User

Ideally all instances of "child" after load would be an instance of my subclass. As I "own" the serialized model, I would like to avoid having to specify the xsi:type for every instance. Is this possible?

Can this be done by modifying the ResourceImpl and subclasssing the SAXXMLHandler? Are there examples you can point me at to get me started?

Re: De-serialization of extended eCore models [message #659861 is a reply to message #659854]

Tue, 15 March 2011 15:45

Eclipse User

Why not just model the child reference to be of the type you want (your
subclass) and be done with it?

JK wrote:
> Ideally all instances of "child" after load would be an instance of my
> subclass. As I "own" the serialized model, I would like to avoid
> having to specify the xsi:type for every instance. Is this possible?
>
> Can this be done by modifying the ResourceImpl and subclasssing the
> SAXXMLHandler? Are there examples you can point me at to get me
> started?

Re: De-serialization of extended eCore models [message #659867 is a reply to message #659861]

Tue, 15 March 2011 16:05

Eclipse User

> Why not just model the child reference to be of the type you want (your
> subclass) and be done with it?

Sorry. I'm not sure I understand what you are saying, or how to go about doing that. The "parent" element, which comes from uri1, holds the reference to 0-* children, and knows nothing about my subclass. I will be subclassing parent to also add an attribute, btw, if that helps.

Re: De-serialization of extended eCore models [message #659881 is a reply to message #659867]

Tue, 15 March 2011 17:14

Eclipse User

You said you own the serialization (which I read to mean the model) and
you want to assume "child" will always be your subclass, so model it
that way.

JK wrote:
>> Why not just model the child reference to be of the type you want
>> (your subclass) and be done with it?
>
> Sorry. I'm not sure I understand what you are saying, or how to go
> about doing that. The "parent" element, which comes from uri1, holds
> the reference to 0-* children, and knows nothing about my subclass.
> I will be subclassing parent to also add an attribute, btw, if that
> helps.

Re: De-serialization of extended eCore models [message #659895 is a reply to message #659881]

Tue, 15 March 2011 19:28

Eclipse User

Thanks Ed. I suspect that I must not be making my situation clear.

The reason I created the uri2 eCore model and extended the uri1 eClasses was because I cannot alter the uri1 eCore model to add attributes. Is there an alternative to subclassing to consider?

When I say I control the serialized model, I mean to say that I know that when an instance is de-serialized, the objects should be either instances of my subclasses when they exist, or uri1 classes when not subclassed. I can modify the serialized instance in whatever manner I want to achieve that, but I would prefer to minimize the effect on the XML. I really don't want to add xsi:type info to every "child" element.

Does this make more sense now, or am I still missing your point?

Re: De-serialization of extended eCore models [message #659898 is a reply to message #659895]

Tue, 15 March 2011 19:42

Eclipse User

JK,

Comments below.

JK wrote:
> Thanks Ed. I suspect that I must not be making my situation clear.
:-P
>
> The reason I created the uri2 eCore model and extended the uri1
> eClasses was because I cannot alter the uri1 eCore model to add
> attributes.
Why not?
> Is there an alternative to subclassing to consider?
No.
>
> When I say I control the serialized model, I mean to say that I know
> that when an instance is de-serialized, the objects should be either
> instances of my subclasses when they exist, or uri1 classes when not
> subclassed. I can modify the serialized instance in whatever manner I
> want to achieve that, but I would prefer to minimize the effect on
> the XML.
Yet you're asking for precisely something that's XML which can't be
processed in a standard way...
> I really don't want to add xsi:type info to every "child" element.
That you've made clear. It's not clear why, though. Is it just an
aesthetic thing? XML is after all horribly ugly and barely fit for
human consumption so trying to make it prettier is a bit like putting
lipstick on a pig. Notice that serializations of Ecore are full of
xsi:type; it doesn't bother me because I don't expect it to be pretty.
In the end, it's just not clear why it's okay to have a serialization
that doesn't conform to the model (nothing else could parse) but it's
not okay to change the model so that the serialization and the model are
in sync...

Is there some existing generated model over which you have no control?
>
> Does this make more sense now, or am I still missing your point?

Re: De-serialization of extended eCore models [message #660080 is a reply to message #659898]

Wed, 16 March 2011 14:18

Eclipse User

Thanks Ed. Let me try again.

>> The reason I created the uri2 eCore model and extended the uri1
>> eClasses was because I cannot alter the uri1 eCore model to add
>> attributes.
> Why not?

In my case, the base eCore model is coming from open source. Even if it wasn't, I would imagine that there are plenty of times that people would like to enhance an eCore model without modifying it.

> Yet you're asking for precisely something that's XML which can't be
> processed in a standard way...

That's a fair criticism.

> ... It's not clear why, though. Is it just an
> aesthetic thing? XML is after all horribly ugly and barely fit for
> human consumption so trying to make it prettier is a bit like putting
> lipstick on a pig. ...

The instances of our models are static files that are always read only. They have either been created using xml editors, or generated as xml from other sources. They are not created using generated EMF editors.

We are taking existing model instances and decorating a handful of the elements with new attributes. But in the absence of that attribute, a default value is implied. It would be so much cleaner to have instances of the child subclass after a load for that reason. The particular reason I would like to avoid adding an xsi:type attribute to every element is because it would make comparing the original model with the decorated one very difficult since there may be hundreds of child elements in the xml file.

> Is there some existing generated model over which you have no control?

Are you asking if we could create our own genmodel for the base eCore model?

Re: De-serialization of extended eCore models [message #660099 is a reply to message #660080]

Wed, 16 March 2011 15:28

Eclipse User

JK,

Comments below.

JK wrote:
> Thanks Ed. Let me try again.
>>> The reason I created the uri2 eCore model and extended the uri1
>>> eClasses was because I cannot alter the uri1 eCore model to add
>>> attributes.
>> Why not?
>
> In my case, the base eCore model is coming from open source. Even if
> it wasn't, I would imagine that there are plenty of times that people
> would like to enhance an eCore model without modifying it.
Indeed.
>
>> Yet you're asking for precisely something that's XML which can't be
>> processed in a standard way...
>
> That's a fair criticism.
>> ... It's not clear why, though. Is it just an aesthetic thing? XML is
>> after all horribly ugly and barely fit for human consumption so
>> trying to make it prettier is a bit like putting lipstick on a pig. ...
>
> The instances of our models are static files that are always read
> only. They have either been created using xml editors, or generated
> as xml from other sources.
So they're being created in a way that conforms to no schemas...
> They are not created using generated EMF editors.
> We are taking existing model instances and decorating a handful of the
> elements with new attributes.
Because the base model didn't anticipate a need for
annotations/decorations...
> But in the absence of that attribute, a default value is implied.
> It would be so much cleaner to have instances of the child subclass
> after a load for that reason. The particular reason I would like to
> avoid adding an xsi:type attribute to every element is because it
> would make comparing the original model with the decorated one very
> difficult since there may be hundreds of child elements in the xml file.
Or you could look at it as just one more attribute; one that indicates
there will be decorations and what model those decorations conform to,
which seems like a good thing...
>
>> Is there some existing generated model over which you have no control?
>
> Are you asking if we could create our own genmodel for the base eCore
> model?
Yes. Or your own modified copy of that. In any case, to achieve what
you want, you'd have to do things like specialize
XMLSaveImpl.saveTypeAttribute to skip doing that in certain cases and
you could specialize XMLHelperImpl.createObject to substitute a derived
class for certain cases. Trying setting a breakpoint in these places
and see how they're invoked when loading and saving...

Previous Topic:	[CDO] Objectivity store
Next Topic:	Proxy resolval for EAttribute

Goto Forum:

-=] Back to Top [=-

Current Time: Mon Jul 07 21:09:54 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter