Eclipse Community Forums: EMF » Strange URI format

Help

Home

Home » Modeling » EMF » Strange URI format

Show: Today's Messages :: Show Polls :: Message Navigator

Strange URI format [message #417022]

Sat, 23 February 2008 02:33

AlesD

Messages: 12
Registered: July 2009

Junior Member

This is a multi-part message in MIME format.
--------------050509080700080004050201
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

I have problem with serialization to XML. When I have attribute with
type xsd:anyURI and ecore:reference to type that is common abstract type
for other types then URIs generated by EMF have following format

realType resourceURI#ID

Here is simple example (XSD and Main class are attached):

<?xml version="1.0" encoding="ASCII"?>
<people:people xmlns:people="http://www.example.org/people">
<people:man name="Tom"
father="parents.xml#David"
mother="parents.xml#Jane"/>
</people:people>

<?xml version="1.0" encoding="ASCII"?>
<people:people xmlns:people="http://www.example.org/people">
<people:man name="David">
<people:child person="people:Man children.xml#Tom"/>
</people:man>
<people:woman name="Jane">
<people:child person="people:Man children.xml#Tom"/>
</people:woman>
</people:people>

Tom has 2 parents - David and Jane. Since father and mother
attributes are of type Man and Woman the links are correct.

On the other hand David and Jane has child element that has
attribute person of type Person - common super type for Man
and Woman. In this case the links have the "strange" format.

<people:child person="people:Man children.xml#Tom"/>

How can I get rid of the type prefix (people:Man)?

AlesD

--------------050509080700080004050201
Content-Type: text/xml;
name="people.xsd"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="people.xsd"

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHhzZDpz Y2hlbWEgdGFy
Z2V0TmFtZXNwYWNlPSJodHRwOi8vd3d3LmV4YW1wbGUub3JnL3Blb3BsZSIK CQl4bWxuczp4
c2Q9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgoJCXhtbG5z OmVjb3JlPSJo
dHRwOi8vd3d3LmVjbGlwc2Uub3JnL2VtZi8yMDAyL0Vjb3JlIgoJCXhtbG5z PSJodHRwOi8v
d3d3LmV4YW1wbGUub3JnL3Blb3BsZSIKCQllbGVtZW50Rm9ybURlZmF1bHQ9 InF1YWxpZmll
ZCI+CgoJPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJQZXJzb24iIGFic3RyYWN0 PSJ0cnVlIj4K
CQk8eHNkOnNlcXVlbmNlPgoJCQk8eHNkOmVsZW1lbnQgbmFtZT0iY2hpbGQi IG1pbk9jY3Vy
cz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPgoJCQkJPHhzZDpjb21wbGV4 VHlwZSBlY29y
ZTpuYW1lPSJDaGlsZCI+CgkJCQkJPHhzZDphdHRyaWJ1dGUgbmFtZT0icGVy c29uIiB0eXBl
PSJ4c2Q6YW55VVJJIgoJCQkJCQkJZWNvcmU6cmVmZXJlbmNlPSJQZXJzb24i Lz4KCQkJCTwv
eHNkOmNvbXBsZXhUeXBlPgoJCQk8L3hzZDplbGVtZW50PgoJCTwveHNkOnNl cXVlbmNlPgoJ
CTx4c2Q6YXR0cmlidXRlIG5hbWU9Im5hbWUiIHR5cGU9InhzZDpJRCIvPgoJ CTx4c2Q6YXR0
cmlidXRlIG5hbWU9ImZhdGhlciIgdHlwZT0ieHNkOmFueVVSSSIKCQkJCWVj b3JlOnJlZmVy
ZW5jZT0iTWFuIi8+CgkJPHhzZDphdHRyaWJ1dGUgbmFtZT0ibW90aGVyIiB0 eXBlPSJ4c2Q6
YW55VVJJIgoJCQkJZWNvcmU6cmVmZXJlbmNlPSJXb21hbiIvPgoJPC94c2Q6 Y29tcGxleFR5
cGU+CgoJPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJXb21hbiI+CgkJPHhzZDpj b21wbGV4Q29u
dGVudD4KCQkJPHhzZDpleHRlbnNpb24gYmFzZT0iUGVyc29uIi8+CgkJPC94 c2Q6Y29tcGxl
eENvbnRlbnQ+Cgk8L3hzZDpjb21wbGV4VHlwZT4KCgk8eHNkOmNvbXBsZXhU eXBlIG5hbWU9
Ik1hbiI+CgkJPHhzZDpjb21wbGV4Q29udGVudD4KCQkJPHhzZDpleHRlbnNp b24gYmFzZT0i
UGVyc29uIi8+CgkJPC94c2Q6Y29tcGxleENvbnRlbnQ+Cgk8L3hzZDpjb21w bGV4VHlwZT4K
Cgk8eHNkOmNvbXBsZXhUeXBlIG5hbWU9IlBlb3BsZSI+CgkJPHhzZDpjaG9p Y2UgbWluT2Nj
dXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCI+CgkJCTx4c2Q6ZWxlbWVu dCBuYW1lPSJt
YW4iIHR5cGU9Ik1hbiIvPgoJCQk8eHNkOmVsZW1lbnQgbmFtZT0id29tYW4i IHR5cGU9Ildv
bWFuIi8+CgkJPC94c2Q6Y2hvaWNlPgoJPC94c2Q6Y29tcGxleFR5cGU+CgoJ PHhzZDplbGVt
ZW50IG5hbWU9InBlb3BsZSIgdHlwZT0iUGVvcGxlIi8+CjwveHNkOnNjaGVt YT4=
--------------050509080700080004050201
Content-Type: text/x-java;
name="Main.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Main.java"

package org.example;

import java.io.IOException;
import java.util.Collections;

import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
import org.example.people.Child;
import org.example.people.DocumentRoot;
import org.example.people.Man;
import org.example.people.People;
import org.example.people.PeopleFactory;
import org.example.people.PeoplePackage;
import org.example.people.Woman;
import org.example.people.util.PeopleResourceFactoryImpl;

public class Main
{

public static void main(String[] args) throws IOException {
PeoplePackage.eINSTANCE.eClass(); // to initialize the package

// create 3 people parents (David and Jane) and one child (Tom)
PeopleFactory pf = PeopleFactory.eINSTANCE;
Man david = pf.createMan();
david.setName("David");
Woman jane = pf.createWoman();
jane.setName("Jane");
Man tom = pf.createMan();
tom.setName("Tom");
tom.setFather(david);
Child child = pf.createChild();
child.setPerson(tom);
david.getChild().add(child);
tom.setMother(jane);
child = pf.createChild();
child.setPerson(tom);
jane.getChild().add(child);

// Now save them into 2 files
PeopleResourceFactoryImpl prf = new PeopleResourceFactoryImpl();

// parents in one
People people = pf.createPeople();
people.getMan().add(david);
people.getWoman().add(jane);
DocumentRoot root = pf.createDocumentRoot();
root.setPeople(people);
Resource parents = prf.createResource(URI.createFileURI("/tmp/parents.xml"));
parents.getContents().add(root);

// child in other
people = pf.createPeople();
people.getMan().add(tom);
root = pf.createDocumentRoot();
root.setPeople(people);
Resource children = prf.createResource(URI.createFileURI("/tmp/children.xml"));
children.getContents().add(root);

// add them to ResourceSet so they can link
ResourceSet rs = new ResourceSetImpl();
rs.getResources().add(parents);
rs.getResources().add(children);

// save both files
parents.save(Collections.EMPTY_MAP);
children.save(Collections.EMPTY_MAP);
}

}

--------------050509080700080004050201--

Report message to a moderator

Re: Strange URI format [message #417027 is a reply to message #417022]

Sat, 23 February 2008 11:44

Ed Merks

Messages: 33137
Registered: July 2009

Senior Member

AlesD,

Comments below.

AlesD wrote:
> Hello,
>
> I have problem with serialization to XML. When I have attribute with
> type xsd:anyURI and ecore:reference to type that is common abstract
> type for other types then URIs generated by EMF have following format
>
> realType resourceURI#ID
This is expected. EMF needs to create a proxy object to hold this
reference until its resolved and since the type of the feature is
abstract, it needs to know about the non-abstract derived type that it
can actually create for the proxy.
>
> Here is simple example (XSD and Main class are attached):
>
> <?xml version="1.0" encoding="ASCII"?>
> <people:people xmlns:people="http://www.example.org/people">
> <people:man name="Tom"
> father="parents.xml#David"
> mother="parents.xml#Jane"/>
> </people:people>
>
> <?xml version="1.0" encoding="ASCII"?>
> <people:people xmlns:people="http://www.example.org/people">
> <people:man name="David">
> <people:child person="people:Man children.xml#Tom"/>
> </people:man>
> <people:woman name="Jane">
> <people:child person="people:Man children.xml#Tom"/>
> </people:woman>
> </people:people>
>
> Tom has 2 parents - David and Jane. Since father and mother
> attributes are of type Man and Woman the links are correct.
>
> On the other hand David and Jane has child element that has
> attribute person of type Person - common super type for Man
> and Woman. In this case the links have the "strange" format.
>
> <people:child person="people:Man children.xml#Tom"/>
>
> How can I get rid of the type prefix (people:Man)?
If you got rid of it, EMF couldn't deserialize it anymore. Make Person
be not abstract, at least in the Ecore model, would eliminate the issue.
Or you could use IDREF instead of anyURI, if it's okay that references
will all have to be in the same resource.
>
> AlesD

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Strange URI format [message #417046 is a reply to message #417027]

Sun, 24 February 2008 19:02

AlesD

Messages: 12
Registered: July 2009

Junior Member

Ed Merks wrote:
> AlesD wrote:
>> Hello,
>>
>> I have problem with serialization to XML. When I have attribute with
>> type xsd:anyURI and ecore:reference to type that is common abstract
>> type for other types then URIs generated by EMF have following format
>>
>> realType resourceURI#ID
> This is expected. EMF needs to create a proxy object to hold this
> reference until its resolved and since the type of the feature is
> abstract, it needs to know about the non-abstract derived type that it
> can actually create for the proxy.

Why it is not possible for EMF code generator to create proxy for abstract
type? Or interface? All methods of the proxy first resolve the reference
and then invoked the method on real object. So the proxy can implement
abstract methods or interface, because it know that the resolved object
can't be abstract - it must be some subtype of the abstract type or some
type implementing the interface.

=> Looking at my example the EMF could generate "PersonProxy" that would
resolve either to Man or Woman.

>> How can I get rid of the type prefix (people:Man)?
> If you got rid of it, EMF couldn't deserialize it anymore. Make Person
> be not abstract, at least in the Ecore model, would eliminate the issue.

I do not need (actually I don't want) implementation of the abstract type.

It is all because XSD does not allow multiple inferitance.

In my real project I also mark it with ecore:interface so it can be
"mixed" into other types. The XSD type does not have any attribtes or
elements I just add methods to it. Here is another short example.

<xsd:attributeGroup name="commonAttribs">
<xsd:attribute name="attr" type="xsd:string"/>
</xsd:attributeGroup>

<xsd:complexType name="Common" abstract="true" ecore:interface="true"/>

<xsd:complexType name="One" ecore:implements="Common">
<xsd:complexContent>
<xsd:extension base="OneBase">
<xsd:attributeGroup ref="commonAttribs"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="Two" ecore:implements="Common">
<xsd:complexContent>
<xsd:extension base="TwoBase">
<xsd:attributeGroup ref="commonAttribs"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

The types One and Two have different superTypes so I create abstract
type Common and let One and Two implement it. The Common should have
attribute "attr", but I can't add it directly to Common - it would not
make sense for the XML Schema since it does not know about
ecore:implements and would not allow "attr" for One and Two. Instead I
create attributeGrou and add it to every Type that implements Common.

The I add method "String getAttr()" to generated Common interface and
have interface for One and Two common attributes/elements.

Any reference to Common, however, will be in the "strange URI format".
But if there was "CommonProxy" it wouldn't be necessary.

Maybe if I could convince the Ecore generator to delegate to super type
attribute/element if the interface/class specified by "ecore:implements"
contains attribute/element already present in the super Type.

> Or you could use IDREF instead of anyURI, if it's okay that references
> will all have to be in the same resource.

Unfortunatelly I need them in different resources.

Hello

Report message to a moderator

Re: Strange URI format [message #417047 is a reply to message #417046]

Sun, 24 February 2008 20:30

Ed Merks

Messages: 33137
Registered: July 2009

Senior Member

AlesD,

Comments below.

AlesD wrote:
> Ed Merks wrote:
>> AlesD wrote:
>>> Hello,
>>>
>>> I have problem with serialization to XML. When I have attribute
>>> with type xsd:anyURI and ecore:reference to type that is common
>>> abstract type for other types then URIs generated by EMF have
>>> following format
>>>
>>> realType resourceURI#ID
>> This is expected. EMF needs to create a proxy object to hold this
>> reference until its resolved and since the type of the feature is
>> abstract, it needs to know about the non-abstract derived type that
>> it can actually create for the proxy.
>
> Why it is not possible for EMF code generator to create proxy for
> abstract
> type? Or interface?
Because, it's abstract and you can't create an instance of an abstract.
There's no generated create method for it.
> All methods of the proxy first resolve the reference
> and then invoked the method on real object. So the proxy can implement
> abstract methods or interface, because it know that the resolved object
> can't be abstract - it must be some subtype of the abstract type or some
> type implementing the interface.
Don't mix the concept of a Java proxy with EMF's analog. For EMF we
need to be able to use EcoreUtil.create to create an instance and for an
abstract type, that's not possible.
>
> => Looking at my example the EMF could generate "PersonProxy" that would
> resolve either to Man or Woman.
It doesn't though. In an EClass is abstract, the AbcImpl for it will
also be abstract, and there will be no possibility to create an instance.
>
>>> How can I get rid of the type prefix (people:Man)?
>> If you got rid of it, EMF couldn't deserialize it anymore. Make
>> Person be not abstract, at least in the Ecore model, would eliminate
>> the issue.
>
> I do not need (actually I don't want) implementation of the abstract
> type.
>
> It is all because XSD does not allow multiple inferitance.
>
> In my real project I also mark it with ecore:interface so it can be
> "mixed" into other types. The XSD type does not have any attribtes or
> elements I just add methods to it. Here is another short example.
>
> <xsd:attributeGroup name="commonAttribs">
> <xsd:attribute name="attr" type="xsd:string"/>
> </xsd:attributeGroup>
>
> <xsd:complexType name="Common" abstract="true" ecore:interface="true"/>
>
> <xsd:complexType name="One" ecore:implements="Common">
> <xsd:complexContent>
> <xsd:extension base="OneBase">
> <xsd:attributeGroup ref="commonAttribs"/>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> <xsd:complexType name="Two" ecore:implements="Common">
> <xsd:complexContent>
> <xsd:extension base="TwoBase">
> <xsd:attributeGroup ref="commonAttribs"/>
> </xsd:extension>
> </xsd:complexContent>
> </xsd:complexType>
>
> The types One and Two have different superTypes so I create abstract
> type Common and let One and Two implement it. The Common should have
> attribute "attr", but I can't add it directly to Common - it would not
> make sense for the XML Schema since it does not know about
> ecore:implements and would not allow "attr" for One and Two. Instead I
> create attributeGrou and add it to every Type that implements Common.
>
> The I add method "String getAttr()" to generated Common interface and
> have interface for One and Two common attributes/elements.
>
> Any reference to Common, however, will be in the "strange URI format".
> But if there was "CommonProxy" it wouldn't be necessary.
There isn't though.
>
> Maybe if I could convince the Ecore generator to delegate to super type
> attribute/element if the interface/class specified by "ecore:implements"
> contains attribute/element already present in the super Type.
I don't really understand...
>
>> Or you could use IDREF instead of anyURI, if it's okay that
>> references will all have to be in the same resource.
>
> Unfortunatelly I need them in different resources.
Maybe it's best then not to make the type abstract. Ecore supports
multiple inheritance (though obviously Java itself doesn't for classes).
>
> Hello

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Strange URI format [message #417048 is a reply to message #417047]

Mon, 25 February 2008 00:47

AlesD

Messages: 12
Registered: July 2009

Junior Member

Ed Merks wrote:
> AlesD wrote:
>> Unfortunatelly I need them in different resources.
> Maybe it's best then not to make the type abstract. Ecore supports
> multiple inheritance (though obviously Java itself doesn't for classes).

Thanks for your patience and explaintation Ed.

I know that I can do it with Ecore, but I start with XML Schema and XSD
unfortunatelly does not allow multiple inheritance. Any good way how to
define it in XSD - except the one I outlined in previous example?

The schema still changes from time to time - so I need to regenerate the
Ecore. Is the XML to Ecore Map used for it?

Mean time I used element instead of attribute the URL looks normal now. It
is not so clean from design point of view, but the extra xsi:type does not
cause problems to 3rd party tools working with XML documents generated by
my application.

AlesD

Report message to a moderator

Re: Strange URI format [message #417049 is a reply to message #417048]

Mon, 25 February 2008 00:43

Ed Merks

Messages: 33137
Registered: July 2009

Senior Member

AlesD,

The only way is to make the type not be abstract so that a proxy of that
type can be created. If you serialize as an element, the type QName
will appear in the xsi:type instead of as part of the URI, so if that's
not a problem, that seems like a good compromise.

AlesD wrote:
> Ed Merks wrote:
>> AlesD wrote:
>>> Unfortunatelly I need them in different resources.
>> Maybe it's best then not to make the type abstract. Ecore supports
>> multiple inheritance (though obviously Java itself doesn't for classes).
>
> Thanks for your patience and explaintation Ed.
>
> I know that I can do it with Ecore, but I start with XML Schema and XSD
> unfortunatelly does not allow multiple inheritance. Any good way how to
> define it in XSD - except the one I outlined in previous example?
>
> The schema still changes from time to time - so I need to regenerate the
> Ecore. Is the XML to Ecore Map used for it?
>
> Mean time I used element instead of attribute the URL looks normal
> now. It
> is not so clean from design point of view, but the extra xsi:type does
> not
> cause problems to 3rd party tools working with XML documents generated by
> my application.
>
> AlesD

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	How to set an attribute value to the value of another attribute in the EMF editor?
Next Topic:	CommandStack in IEditingDomainProvider

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 23:00:45 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter