Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » More XSD -> EMF -> UML Issues
More XSD -> EMF -> UML Issues [message #478342] Tue, 28 April 2009 20:13 Go to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Using the following library example schema:

<xsd:schema targetNamespace="http://www.example.eclipse.org/Library"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
xmlns:lib="http://www.example.eclipse.org/Library"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="library" type="lib:Library"/>
<xsd:complexType name="Book">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="pages" type="xsd:int"/>
<xsd:element name="category" type="lib:BookCategory"/>
<xsd:element name="author" type="xsd:anyURI"
ecore:reference="lib:Writer" ecore:opposite="books"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Writer">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="books"
type="xsd:anyURI" ecore:reference="lib:Book"
ecore:opposite="author"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Library">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element maxOccurs="unbounded" minOccurs="0"
name="writers" type="lib:Writer"/>
<xsd:element maxOccurs="unbounded" minOccurs="0"
name="books" type="lib:Book"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="BookCategory">
<xsd:restriction base="xsd:NCName">
<xsd:enumeration value="Mystery"/>
<xsd:enumeration value="ScienceFiction"/>
<xsd:enumeration value="Biography"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

I import the above schema into EMF and then use the "Export Model..." to
generate create UML. In addition to issues previously mentioned (for which
I have submitted bug reports), I am running into a problem when I want to
go back to EMF from UML. Ideally, I would like to add OCL constraints to
the UML and then import back into EMF. This part seems to work fine. The
issue I am having is related to serializing to XML. Using the following
test code:

Writer author = LibraryFactory.eINSTANCE.createWriter();
author.setName("Some Author");

Book book = LibraryFactory.eINSTANCE.createBook();
book.setAuthor(author);
book.setCategory(BookCategory.SCIENCE_FICTION);
book.setTitle("Some Title");
book.setPages(100);

Library library = LibraryFactory.eINSTANCE.createLibrary();
library.setName("Some Library");
library.getWriters().add(author);
library.getBooks().add(book);

DocumentRoot root = LibraryFactory.eINSTANCE.createDocumentRoot();
root.setLibrary(library);

Resource.Factory factory = new LibraryResourceFactoryImpl();
XMLResource resource = (XMLResource)
factory.createResource(URI.createURI(LibraryPackage.eNS_URI) );
resource.getContents().add(root);
resource.save(System.out, null);

I get a NullPointerException, that I have tracked down to differences
between XSD->EMF and XSD->EMF->UML->EMF generated code. Specifically, in
LibraryPackageImpl.java, the following line:

// XSD->EMF generated code (WORKING):
initEReference(getDocumentRoot_Library(), this.getLibrary(), null,
"library", null, 0, -2, null, IS_TRANSIENT, IS_VOLATILE, IS_CHANGEABLE,
IS_COMPOSITE, !IS_RESOLVE_PROXIES, !IS_UNSETTABLE, IS_UNIQUE, IS_DERIVED,
IS_ORDERED);

// XSD->EMF->UML->EMF generated code (NOT WORKING):
initEReference(getDocumentRoot_Library(), this.getLibrary(), null,
"library", null, 0, 1, null, IS_TRANSIENT, IS_VOLATILE, IS_CHANGEABLE,
!IS_COMPOSITE, !IS_RESOLVE_PROXIES, !IS_UNSETTABLE, IS_UNIQUE, IS_DERIVED,
IS_ORDERED);

There differences are:

In the working ocde, the upperBound parameter is set to -2 (unspecified)
and the isContainment parameter is set to IS_COMPOSITE.

In the non-working code, the upperBound parameter is set to 1 and the
isContaintment parameter is set to !IS_COMPOSITE.

The upperBound parameter doesn't make a difference. However, if I change
!IS_COMPOSITE to IS_COMPOSITE in the non-working code, I no longer get a
null pointer exception. IS_COMPOSITE, should be true as the UML model
shows property "Aggregation" as "Composite" for the DocumentRoot.library
property. Not sure why it gets set the way it does. Any ideas?

Thanks,

JT
Re: More XSD -> EMF -> UML Issues [message #478345 is a reply to message #478342] Wed, 29 April 2009 05:48 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
I discovered that during the EMF->UML import process, the containment
reference "library" in DocumentRoot is marked as "derived" in the UML
model. This causes a problem during the UML->EMF import process.
Apparently contaiment references marked as "derived" do not set the
"Containment" property on the EReference which ultimately leads to the
serialization issues that I am seeing in this example.
Re: More XSD -> EMF -> UML Issues [message #478346 is a reply to message #478345] Wed, 29 April 2009 10:07 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 32440
Registered: July 2009
Senior Member
John,

Probably the exporter should be taking into account that the containment
derivation is from a feature map rather than being derived from another
containment reference in which case it denotes subsetting.

Note that you should be able to add OCL constraints directly to the
XSD. To see how, just take an Ecore file that has the constraints in
the form you desire, export it to an XML Schema, and have a look at how
that Ecore EAnnotations are expressed as XML Schema annotations...


John T.E. Timm wrote:
> I discovered that during the EMF->UML import process, the containment
> reference "library" in DocumentRoot is marked as "derived" in the UML
> model. This causes a problem during the UML->EMF import process.
> Apparently contaiment references marked as "derived" do not set the
> "Containment" property on the EReference which ultimately leads to the
> serialization issues that I am seeing in this example.
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: More XSD -> EMF -> UML Issues [message #478347 is a reply to message #478346] Wed, 29 April 2009 16:20 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Though I do like the ability to add OCL directly to schema via
annotations, I have a requirement to be in UML as there are existing
models that will reference these models and will be part of the UML->EMF
conversion process to get to code generation with OCL.

Some of the other references (e.g. Writer.books) have "Composition" set in
the UML model but this does not translate to having "Containment" set in
the EMF when going from UML->EMF. I have to study further what actually
triggers Containment to be set. In the UML2EcoreConverter it looks like
property.isComposite is called to determine some of the behavior, so I
would figure that all of the associations in the UML model that are
"Composition" should be transferred through which is clearly not the case.

JT

Ed Merks wrote:

> John,

> Probably the exporter should be taking into account that the containment
> derivation is from a feature map rather than being derived from another
> containment reference in which case it denotes subsetting.

> Note that you should be able to add OCL constraints directly to the
> XSD. To see how, just take an Ecore file that has the constraints in
> the form you desire, export it to an XML Schema, and have a look at how
> that Ecore EAnnotations are expressed as XML Schema annotations...


> John T.E. Timm wrote:
>> I discovered that during the EMF->UML import process, the containment
>> reference "library" in DocumentRoot is marked as "derived" in the UML
>> model. This causes a problem during the UML->EMF import process.
>> Apparently contaiment references marked as "derived" do not set the
>> "Containment" property on the EReference which ultimately leads to the
>> serialization issues that I am seeing in this example.
>>
Re: More XSD -> EMF -> UML Issues [message #478348 is a reply to message #478347] Wed, 29 April 2009 16:52 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Actually a clarification on this:

It looks like Writer.books is fine as is Library.books and
Library.writers. They start out with Containment set in the Ecore which
translates to Composition in the UML which translates back to Containment
in the Ecore. So basically, the problem is in marking the composition as
"derived" for the special case of DocumentRoot.library.

On another side note, none of the xmlNames are transferred through from
Ecore to properties of the eClass, eAttribute, and eReference stereotypes.

JT

John T.E. Timm wrote:

> Though I do like the ability to add OCL directly to schema via
> annotations, I have a requirement to be in UML as there are existing
> models that will reference these models and will be part of the UML->EMF
> conversion process to get to code generation with OCL.

> Some of the other references (e.g. Writer.books) have "Composition" set in
> the UML model but this does not translate to having "Containment" set in
> the EMF when going from UML->EMF. I have to study further what actually
> triggers Containment to be set. In the UML2EcoreConverter it looks like
> property.isComposite is called to determine some of the behavior, so I
> would figure that all of the associations in the UML model that are
> "Composition" should be transferred through which is clearly not the case.

> JT

> Ed Merks wrote:

>> John,

>> Probably the exporter should be taking into account that the containment
>> derivation is from a feature map rather than being derived from another
>> containment reference in which case it denotes subsetting.

>> Note that you should be able to add OCL constraints directly to the
>> XSD. To see how, just take an Ecore file that has the constraints in
>> the form you desire, export it to an XML Schema, and have a look at how
>> that Ecore EAnnotations are expressed as XML Schema annotations...


>> John T.E. Timm wrote:
>>> I discovered that during the EMF->UML import process, the containment
>>> reference "library" in DocumentRoot is marked as "derived" in the UML
>>> model. This causes a problem during the UML->EMF import process.
>>> Apparently contaiment references marked as "derived" do not set the
>>> "Containment" property on the EReference which ultimately leads to the
>>> serialization issues that I am seeing in this example.
>>>
Re: More XSD -> EMF -> UML Issues [message #478349 is a reply to message #478348] Wed, 29 April 2009 17:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 32440
Registered: July 2009
Senior Member
John,

Probably there's an option to preserve the EAnnotations?


John T.E. Timm wrote:
> Actually a clarification on this:
>
> It looks like Writer.books is fine as is Library.books and
> Library.writers. They start out with Containment set in the Ecore
> which translates to Composition in the UML which translates back to
> Containment in the Ecore. So basically, the problem is in marking the
> composition as "derived" for the special case of DocumentRoot.library.
>
> On another side note, none of the xmlNames are transferred through
> from Ecore to properties of the eClass, eAttribute, and eReference
> stereotypes.
>
> JT
>
> John T.E. Timm wrote:
>
>> Though I do like the ability to add OCL directly to schema via
>> annotations, I have a requirement to be in UML as there are existing
>> models that will reference these models and will be part of the
>> UML->EMF conversion process to get to code generation with OCL.
>
>> Some of the other references (e.g. Writer.books) have "Composition"
>> set in the UML model but this does not translate to having
>> "Containment" set in the EMF when going from UML->EMF. I have to
>> study further what actually triggers Containment to be set. In the
>> UML2EcoreConverter it looks like property.isComposite is called to
>> determine some of the behavior, so I would figure that all of the
>> associations in the UML model that are "Composition" should be
>> transferred through which is clearly not the case.
>
>> JT
>
>> Ed Merks wrote:
>
>>> John,
>
>>> Probably the exporter should be taking into account that the
>>> containment derivation is from a feature map rather than being
>>> derived from another containment reference in which case it denotes
>>> subsetting.
>
>>> Note that you should be able to add OCL constraints directly to the
>>> XSD. To see how, just take an Ecore file that has the constraints
>>> in the form you desire, export it to an XML Schema, and have a look
>>> at how that Ecore EAnnotations are expressed as XML Schema
>>> annotations...
>
>
>>> John T.E. Timm wrote:
>>>> I discovered that during the EMF->UML import process, the
>>>> containment reference "library" in DocumentRoot is marked as
>>>> "derived" in the UML model. This causes a problem during the
>>>> UML->EMF import process. Apparently contaiment references marked as
>>>> "derived" do not set the "Containment" property on the EReference
>>>> which ultimately leads to the serialization issues that I am seeing
>>>> in this example.
>>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: More XSD -> EMF -> UML Issues [message #478350 is a reply to message #478349] Wed, 29 April 2009 20:55 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Ed,

Even with "Process All" selected it doesn't carry over the xml names to
the UML model.

Ed Merks wrote:

> John,

> Probably there's an option to preserve the EAnnotations?


> John T.E. Timm wrote:
>> Actually a clarification on this:
>>
>> It looks like Writer.books is fine as is Library.books and
>> Library.writers. They start out with Containment set in the Ecore
>> which translates to Composition in the UML which translates back to
>> Containment in the Ecore. So basically, the problem is in marking the
>> composition as "derived" for the special case of DocumentRoot.library.
>>
>> On another side note, none of the xmlNames are transferred through
>> from Ecore to properties of the eClass, eAttribute, and eReference
>> stereotypes.
>>
>> JT
>>
>> John T.E. Timm wrote:
>>
>>> Though I do like the ability to add OCL directly to schema via
>>> annotations, I have a requirement to be in UML as there are existing
>>> models that will reference these models and will be part of the
>>> UML->EMF conversion process to get to code generation with OCL.
>>
>>> Some of the other references (e.g. Writer.books) have "Composition"
>>> set in the UML model but this does not translate to having
>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>> study further what actually triggers Containment to be set. In the
>>> UML2EcoreConverter it looks like property.isComposite is called to
>>> determine some of the behavior, so I would figure that all of the
>>> associations in the UML model that are "Composition" should be
>>> transferred through which is clearly not the case.
>>
>>> JT
>>
>>> Ed Merks wrote:
>>
>>>> John,
>>
>>>> Probably the exporter should be taking into account that the
>>>> containment derivation is from a feature map rather than being
>>>> derived from another containment reference in which case it denotes
>>>> subsetting.
>>
>>>> Note that you should be able to add OCL constraints directly to the
>>>> XSD. To see how, just take an Ecore file that has the constraints
>>>> in the form you desire, export it to an XML Schema, and have a look
>>>> at how that Ecore EAnnotations are expressed as XML Schema
>>>> annotations...
>>
>>
>>>> John T.E. Timm wrote:
>>>>> I discovered that during the EMF->UML import process, the
>>>>> containment reference "library" in DocumentRoot is marked as
>>>>> "derived" in the UML model. This causes a problem during the
>>>>> UML->EMF import process. Apparently contaiment references marked as
>>>>> "derived" do not set the "Containment" property on the EReference
>>>>> which ultimately leads to the serialization issues that I am seeing
>>>>> in this example.
>>>>>
>>
>>
Re: More XSD -> EMF -> UML Issues [message #478351 is a reply to message #478350] Wed, 29 April 2009 21:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 32440
Registered: July 2009
Senior Member
John,

That sucks especially given that UML extends EModelElement so that
everything can have an EAnnotation...


John T.E. Timm wrote:
> Ed,
>
> Even with "Process All" selected it doesn't carry over the xml names
> to the UML model.
>
> Ed Merks wrote:
>
>> John,
>
>> Probably there's an option to preserve the EAnnotations?
>
>
>> John T.E. Timm wrote:
>>> Actually a clarification on this:
>>>
>>> It looks like Writer.books is fine as is Library.books and
>>> Library.writers. They start out with Containment set in the Ecore
>>> which translates to Composition in the UML which translates back to
>>> Containment in the Ecore. So basically, the problem is in marking
>>> the composition as "derived" for the special case of
>>> DocumentRoot.library.
>>>
>>> On another side note, none of the xmlNames are transferred through
>>> from Ecore to properties of the eClass, eAttribute, and eReference
>>> stereotypes.
>>>
>>> JT
>>>
>>> John T.E. Timm wrote:
>>>
>>>> Though I do like the ability to add OCL directly to schema via
>>>> annotations, I have a requirement to be in UML as there are
>>>> existing models that will reference these models and will be part
>>>> of the UML->EMF conversion process to get to code generation with OCL.
>>>
>>>> Some of the other references (e.g. Writer.books) have "Composition"
>>>> set in the UML model but this does not translate to having
>>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>>> study further what actually triggers Containment to be set. In the
>>>> UML2EcoreConverter it looks like property.isComposite is called to
>>>> determine some of the behavior, so I would figure that all of the
>>>> associations in the UML model that are "Composition" should be
>>>> transferred through which is clearly not the case.
>>>
>>>> JT
>>>
>>>> Ed Merks wrote:
>>>
>>>>> John,
>>>
>>>>> Probably the exporter should be taking into account that the
>>>>> containment derivation is from a feature map rather than being
>>>>> derived from another containment reference in which case it
>>>>> denotes subsetting.
>>>
>>>>> Note that you should be able to add OCL constraints directly to
>>>>> the XSD. To see how, just take an Ecore file that has the
>>>>> constraints in the form you desire, export it to an XML Schema,
>>>>> and have a look at how that Ecore EAnnotations are expressed as
>>>>> XML Schema annotations...
>>>
>>>
>>>>> John T.E. Timm wrote:
>>>>>> I discovered that during the EMF->UML import process, the
>>>>>> containment reference "library" in DocumentRoot is marked as
>>>>>> "derived" in the UML model. This causes a problem during the
>>>>>> UML->EMF import process. Apparently contaiment references marked
>>>>>> as "derived" do not set the "Containment" property on the
>>>>>> EReference which ultimately leads to the serialization issues
>>>>>> that I am seeing in this example.
>>>>>>
>>>
>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: More XSD -> EMF -> UML Issues [message #478352 is a reply to message #478351] Wed, 29 April 2009 21:49 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Ed,

The XML Name does transfer for property types stereotyped as
<<eReference>> in DocumentRoot (e.g. xMLNSPrefixMap and xSISchemaLocation)
but not for anything else...

Ed Merks wrote:

> John,

> That sucks especially given that UML extends EModelElement so that
> everything can have an EAnnotation...


> John T.E. Timm wrote:
>> Ed,
>>
>> Even with "Process All" selected it doesn't carry over the xml names
>> to the UML model.
>>
>> Ed Merks wrote:
>>
>>> John,
>>
>>> Probably there's an option to preserve the EAnnotations?
>>
>>
>>> John T.E. Timm wrote:
>>>> Actually a clarification on this:
>>>>
>>>> It looks like Writer.books is fine as is Library.books and
>>>> Library.writers. They start out with Containment set in the Ecore
>>>> which translates to Composition in the UML which translates back to
>>>> Containment in the Ecore. So basically, the problem is in marking
>>>> the composition as "derived" for the special case of
>>>> DocumentRoot.library.
>>>>
>>>> On another side note, none of the xmlNames are transferred through
>>>> from Ecore to properties of the eClass, eAttribute, and eReference
>>>> stereotypes.
>>>>
>>>> JT
>>>>
>>>> John T.E. Timm wrote:
>>>>
>>>>> Though I do like the ability to add OCL directly to schema via
>>>>> annotations, I have a requirement to be in UML as there are
>>>>> existing models that will reference these models and will be part
>>>>> of the UML->EMF conversion process to get to code generation with OCL.
>>>>
>>>>> Some of the other references (e.g. Writer.books) have "Composition"
>>>>> set in the UML model but this does not translate to having
>>>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>>>> study further what actually triggers Containment to be set. In the
>>>>> UML2EcoreConverter it looks like property.isComposite is called to
>>>>> determine some of the behavior, so I would figure that all of the
>>>>> associations in the UML model that are "Composition" should be
>>>>> transferred through which is clearly not the case.
>>>>
>>>>> JT
>>>>
>>>>> Ed Merks wrote:
>>>>
>>>>>> John,
>>>>
>>>>>> Probably the exporter should be taking into account that the
>>>>>> containment derivation is from a feature map rather than being
>>>>>> derived from another containment reference in which case it
>>>>>> denotes subsetting.
>>>>
>>>>>> Note that you should be able to add OCL constraints directly to
>>>>>> the XSD. To see how, just take an Ecore file that has the
>>>>>> constraints in the form you desire, export it to an XML Schema,
>>>>>> and have a look at how that Ecore EAnnotations are expressed as
>>>>>> XML Schema annotations...
>>>>
>>>>
>>>>>> John T.E. Timm wrote:
>>>>>>> I discovered that during the EMF->UML import process, the
>>>>>>> containment reference "library" in DocumentRoot is marked as
>>>>>>> "derived" in the UML model. This causes a problem during the
>>>>>>> UML->EMF import process. Apparently contaiment references marked
>>>>>>> as "derived" do not set the "Containment" property on the
>>>>>>> EReference which ultimately leads to the serialization issues
>>>>>>> that I am seeing in this example.
>>>>>>>
>>>>
>>>>
>>
>>
Re: More XSD -> EMF -> UML Issues [message #478357 is a reply to message #478352] Fri, 01 May 2009 20:45 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi John,

Please raise separate bugs on all the issues you are encountering. It
appears there are holes in the complete round trip story for converting from
XSD -> EMF -> UML and back.

- James.

"John T.E. Timm" <johntimm@us.ibm.com> wrote in message
news:c11e2f46ab0f6b35afa49ee4c19a6013$1@www.eclipse.org...
> Ed,
>
> The XML Name does transfer for property types stereotyped as
> <<eReference>> in DocumentRoot (e.g. xMLNSPrefixMap and xSISchemaLocation)
> but not for anything else...
>
> Ed Merks wrote:
>
>> John,
>
>> That sucks especially given that UML extends EModelElement so that
>> everything can have an EAnnotation...
>
>
>> John T.E. Timm wrote:
>>> Ed,
>>>
>>> Even with "Process All" selected it doesn't carry over the xml names to
>>> the UML model.
>>>
>>> Ed Merks wrote:
>>>
>>>> John,
>>>
>>>> Probably there's an option to preserve the EAnnotations?
>>>
>>>
>>>> John T.E. Timm wrote:
>>>>> Actually a clarification on this:
>>>>>
>>>>> It looks like Writer.books is fine as is Library.books and
>>>>> Library.writers. They start out with Containment set in the Ecore
>>>>> which translates to Composition in the UML which translates back to
>>>>> Containment in the Ecore. So basically, the problem is in marking the
>>>>> composition as "derived" for the special case of DocumentRoot.library.
>>>>>
>>>>> On another side note, none of the xmlNames are transferred through
>>>>> from Ecore to properties of the eClass, eAttribute, and eReference
>>>>> stereotypes.
>>>>>
>>>>> JT
>>>>>
>>>>> John T.E. Timm wrote:
>>>>>
>>>>>> Though I do like the ability to add OCL directly to schema via
>>>>>> annotations, I have a requirement to be in UML as there are existing
>>>>>> models that will reference these models and will be part of the
>>>>>> UML->EMF conversion process to get to code generation with OCL.
>>>>>
>>>>>> Some of the other references (e.g. Writer.books) have "Composition"
>>>>>> set in the UML model but this does not translate to having
>>>>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>>>>> study further what actually triggers Containment to be set. In the
>>>>>> UML2EcoreConverter it looks like property.isComposite is called to
>>>>>> determine some of the behavior, so I would figure that all of the
>>>>>> associations in the UML model that are "Composition" should be
>>>>>> transferred through which is clearly not the case.
>>>>>
>>>>>> JT
>>>>>
>>>>>> Ed Merks wrote:
>>>>>
>>>>>>> John,
>>>>>
>>>>>>> Probably the exporter should be taking into account that the
>>>>>>> containment derivation is from a feature map rather than being
>>>>>>> derived from another containment reference in which case it denotes
>>>>>>> subsetting.
>>>>>
>>>>>>> Note that you should be able to add OCL constraints directly to the
>>>>>>> XSD. To see how, just take an Ecore file that has the constraints
>>>>>>> in the form you desire, export it to an XML Schema, and have a look
>>>>>>> at how that Ecore EAnnotations are expressed as XML Schema
>>>>>>> annotations...
>>>>>
>>>>>
>>>>>>> John T.E. Timm wrote:
>>>>>>>> I discovered that during the EMF->UML import process, the
>>>>>>>> containment reference "library" in DocumentRoot is marked as
>>>>>>>> "derived" in the UML model. This causes a problem during the
>>>>>>>> UML->EMF import process. Apparently contaiment references marked as
>>>>>>>> "derived" do not set the "Containment" property on the EReference
>>>>>>>> which ultimately leads to the serialization issues that I am seeing
>>>>>>>> in this example.
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: More XSD -> EMF -> UML Issues [message #627532 is a reply to message #478342] Wed, 29 April 2009 05:48 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
I discovered that during the EMF->UML import process, the containment
reference "library" in DocumentRoot is marked as "derived" in the UML
model. This causes a problem during the UML->EMF import process.
Apparently contaiment references marked as "derived" do not set the
"Containment" property on the EReference which ultimately leads to the
serialization issues that I am seeing in this example.
Re: More XSD -> EMF -> UML Issues [message #627533 is a reply to message #478345] Wed, 29 April 2009 10:07 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 32440
Registered: July 2009
Senior Member
John,

Probably the exporter should be taking into account that the containment
derivation is from a feature map rather than being derived from another
containment reference in which case it denotes subsetting.

Note that you should be able to add OCL constraints directly to the
XSD. To see how, just take an Ecore file that has the constraints in
the form you desire, export it to an XML Schema, and have a look at how
that Ecore EAnnotations are expressed as XML Schema annotations...


John T.E. Timm wrote:
> I discovered that during the EMF->UML import process, the containment
> reference "library" in DocumentRoot is marked as "derived" in the UML
> model. This causes a problem during the UML->EMF import process.
> Apparently contaiment references marked as "derived" do not set the
> "Containment" property on the EReference which ultimately leads to the
> serialization issues that I am seeing in this example.
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: More XSD -> EMF -> UML Issues [message #627534 is a reply to message #478346] Wed, 29 April 2009 16:20 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Though I do like the ability to add OCL directly to schema via
annotations, I have a requirement to be in UML as there are existing
models that will reference these models and will be part of the UML->EMF
conversion process to get to code generation with OCL.

Some of the other references (e.g. Writer.books) have "Composition" set in
the UML model but this does not translate to having "Containment" set in
the EMF when going from UML->EMF. I have to study further what actually
triggers Containment to be set. In the UML2EcoreConverter it looks like
property.isComposite is called to determine some of the behavior, so I
would figure that all of the associations in the UML model that are
"Composition" should be transferred through which is clearly not the case.

JT

Ed Merks wrote:

> John,

> Probably the exporter should be taking into account that the containment
> derivation is from a feature map rather than being derived from another
> containment reference in which case it denotes subsetting.

> Note that you should be able to add OCL constraints directly to the
> XSD. To see how, just take an Ecore file that has the constraints in
> the form you desire, export it to an XML Schema, and have a look at how
> that Ecore EAnnotations are expressed as XML Schema annotations...


> John T.E. Timm wrote:
>> I discovered that during the EMF->UML import process, the containment
>> reference "library" in DocumentRoot is marked as "derived" in the UML
>> model. This causes a problem during the UML->EMF import process.
>> Apparently contaiment references marked as "derived" do not set the
>> "Containment" property on the EReference which ultimately leads to the
>> serialization issues that I am seeing in this example.
>>
Re: More XSD -> EMF -> UML Issues [message #627535 is a reply to message #478347] Wed, 29 April 2009 16:52 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Actually a clarification on this:

It looks like Writer.books is fine as is Library.books and
Library.writers. They start out with Containment set in the Ecore which
translates to Composition in the UML which translates back to Containment
in the Ecore. So basically, the problem is in marking the composition as
"derived" for the special case of DocumentRoot.library.

On another side note, none of the xmlNames are transferred through from
Ecore to properties of the eClass, eAttribute, and eReference stereotypes.

JT

John T.E. Timm wrote:

> Though I do like the ability to add OCL directly to schema via
> annotations, I have a requirement to be in UML as there are existing
> models that will reference these models and will be part of the UML->EMF
> conversion process to get to code generation with OCL.

> Some of the other references (e.g. Writer.books) have "Composition" set in
> the UML model but this does not translate to having "Containment" set in
> the EMF when going from UML->EMF. I have to study further what actually
> triggers Containment to be set. In the UML2EcoreConverter it looks like
> property.isComposite is called to determine some of the behavior, so I
> would figure that all of the associations in the UML model that are
> "Composition" should be transferred through which is clearly not the case.

> JT

> Ed Merks wrote:

>> John,

>> Probably the exporter should be taking into account that the containment
>> derivation is from a feature map rather than being derived from another
>> containment reference in which case it denotes subsetting.

>> Note that you should be able to add OCL constraints directly to the
>> XSD. To see how, just take an Ecore file that has the constraints in
>> the form you desire, export it to an XML Schema, and have a look at how
>> that Ecore EAnnotations are expressed as XML Schema annotations...


>> John T.E. Timm wrote:
>>> I discovered that during the EMF->UML import process, the containment
>>> reference "library" in DocumentRoot is marked as "derived" in the UML
>>> model. This causes a problem during the UML->EMF import process.
>>> Apparently contaiment references marked as "derived" do not set the
>>> "Containment" property on the EReference which ultimately leads to the
>>> serialization issues that I am seeing in this example.
>>>
Re: More XSD -> EMF -> UML Issues [message #627536 is a reply to message #478348] Wed, 29 April 2009 17:33 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 32440
Registered: July 2009
Senior Member
John,

Probably there's an option to preserve the EAnnotations?


John T.E. Timm wrote:
> Actually a clarification on this:
>
> It looks like Writer.books is fine as is Library.books and
> Library.writers. They start out with Containment set in the Ecore
> which translates to Composition in the UML which translates back to
> Containment in the Ecore. So basically, the problem is in marking the
> composition as "derived" for the special case of DocumentRoot.library.
>
> On another side note, none of the xmlNames are transferred through
> from Ecore to properties of the eClass, eAttribute, and eReference
> stereotypes.
>
> JT
>
> John T.E. Timm wrote:
>
>> Though I do like the ability to add OCL directly to schema via
>> annotations, I have a requirement to be in UML as there are existing
>> models that will reference these models and will be part of the
>> UML->EMF conversion process to get to code generation with OCL.
>
>> Some of the other references (e.g. Writer.books) have "Composition"
>> set in the UML model but this does not translate to having
>> "Containment" set in the EMF when going from UML->EMF. I have to
>> study further what actually triggers Containment to be set. In the
>> UML2EcoreConverter it looks like property.isComposite is called to
>> determine some of the behavior, so I would figure that all of the
>> associations in the UML model that are "Composition" should be
>> transferred through which is clearly not the case.
>
>> JT
>
>> Ed Merks wrote:
>
>>> John,
>
>>> Probably the exporter should be taking into account that the
>>> containment derivation is from a feature map rather than being
>>> derived from another containment reference in which case it denotes
>>> subsetting.
>
>>> Note that you should be able to add OCL constraints directly to the
>>> XSD. To see how, just take an Ecore file that has the constraints
>>> in the form you desire, export it to an XML Schema, and have a look
>>> at how that Ecore EAnnotations are expressed as XML Schema
>>> annotations...
>
>
>>> John T.E. Timm wrote:
>>>> I discovered that during the EMF->UML import process, the
>>>> containment reference "library" in DocumentRoot is marked as
>>>> "derived" in the UML model. This causes a problem during the
>>>> UML->EMF import process. Apparently contaiment references marked as
>>>> "derived" do not set the "Containment" property on the EReference
>>>> which ultimately leads to the serialization issues that I am seeing
>>>> in this example.
>>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: More XSD -> EMF -> UML Issues [message #627537 is a reply to message #478349] Wed, 29 April 2009 20:55 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Ed,

Even with "Process All" selected it doesn't carry over the xml names to
the UML model.

Ed Merks wrote:

> John,

> Probably there's an option to preserve the EAnnotations?


> John T.E. Timm wrote:
>> Actually a clarification on this:
>>
>> It looks like Writer.books is fine as is Library.books and
>> Library.writers. They start out with Containment set in the Ecore
>> which translates to Composition in the UML which translates back to
>> Containment in the Ecore. So basically, the problem is in marking the
>> composition as "derived" for the special case of DocumentRoot.library.
>>
>> On another side note, none of the xmlNames are transferred through
>> from Ecore to properties of the eClass, eAttribute, and eReference
>> stereotypes.
>>
>> JT
>>
>> John T.E. Timm wrote:
>>
>>> Though I do like the ability to add OCL directly to schema via
>>> annotations, I have a requirement to be in UML as there are existing
>>> models that will reference these models and will be part of the
>>> UML->EMF conversion process to get to code generation with OCL.
>>
>>> Some of the other references (e.g. Writer.books) have "Composition"
>>> set in the UML model but this does not translate to having
>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>> study further what actually triggers Containment to be set. In the
>>> UML2EcoreConverter it looks like property.isComposite is called to
>>> determine some of the behavior, so I would figure that all of the
>>> associations in the UML model that are "Composition" should be
>>> transferred through which is clearly not the case.
>>
>>> JT
>>
>>> Ed Merks wrote:
>>
>>>> John,
>>
>>>> Probably the exporter should be taking into account that the
>>>> containment derivation is from a feature map rather than being
>>>> derived from another containment reference in which case it denotes
>>>> subsetting.
>>
>>>> Note that you should be able to add OCL constraints directly to the
>>>> XSD. To see how, just take an Ecore file that has the constraints
>>>> in the form you desire, export it to an XML Schema, and have a look
>>>> at how that Ecore EAnnotations are expressed as XML Schema
>>>> annotations...
>>
>>
>>>> John T.E. Timm wrote:
>>>>> I discovered that during the EMF->UML import process, the
>>>>> containment reference "library" in DocumentRoot is marked as
>>>>> "derived" in the UML model. This causes a problem during the
>>>>> UML->EMF import process. Apparently contaiment references marked as
>>>>> "derived" do not set the "Containment" property on the EReference
>>>>> which ultimately leads to the serialization issues that I am seeing
>>>>> in this example.
>>>>>
>>
>>
Re: More XSD -> EMF -> UML Issues [message #627538 is a reply to message #478350] Wed, 29 April 2009 21:46 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 32440
Registered: July 2009
Senior Member
John,

That sucks especially given that UML extends EModelElement so that
everything can have an EAnnotation...


John T.E. Timm wrote:
> Ed,
>
> Even with "Process All" selected it doesn't carry over the xml names
> to the UML model.
>
> Ed Merks wrote:
>
>> John,
>
>> Probably there's an option to preserve the EAnnotations?
>
>
>> John T.E. Timm wrote:
>>> Actually a clarification on this:
>>>
>>> It looks like Writer.books is fine as is Library.books and
>>> Library.writers. They start out with Containment set in the Ecore
>>> which translates to Composition in the UML which translates back to
>>> Containment in the Ecore. So basically, the problem is in marking
>>> the composition as "derived" for the special case of
>>> DocumentRoot.library.
>>>
>>> On another side note, none of the xmlNames are transferred through
>>> from Ecore to properties of the eClass, eAttribute, and eReference
>>> stereotypes.
>>>
>>> JT
>>>
>>> John T.E. Timm wrote:
>>>
>>>> Though I do like the ability to add OCL directly to schema via
>>>> annotations, I have a requirement to be in UML as there are
>>>> existing models that will reference these models and will be part
>>>> of the UML->EMF conversion process to get to code generation with OCL.
>>>
>>>> Some of the other references (e.g. Writer.books) have "Composition"
>>>> set in the UML model but this does not translate to having
>>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>>> study further what actually triggers Containment to be set. In the
>>>> UML2EcoreConverter it looks like property.isComposite is called to
>>>> determine some of the behavior, so I would figure that all of the
>>>> associations in the UML model that are "Composition" should be
>>>> transferred through which is clearly not the case.
>>>
>>>> JT
>>>
>>>> Ed Merks wrote:
>>>
>>>>> John,
>>>
>>>>> Probably the exporter should be taking into account that the
>>>>> containment derivation is from a feature map rather than being
>>>>> derived from another containment reference in which case it
>>>>> denotes subsetting.
>>>
>>>>> Note that you should be able to add OCL constraints directly to
>>>>> the XSD. To see how, just take an Ecore file that has the
>>>>> constraints in the form you desire, export it to an XML Schema,
>>>>> and have a look at how that Ecore EAnnotations are expressed as
>>>>> XML Schema annotations...
>>>
>>>
>>>>> John T.E. Timm wrote:
>>>>>> I discovered that during the EMF->UML import process, the
>>>>>> containment reference "library" in DocumentRoot is marked as
>>>>>> "derived" in the UML model. This causes a problem during the
>>>>>> UML->EMF import process. Apparently contaiment references marked
>>>>>> as "derived" do not set the "Containment" property on the
>>>>>> EReference which ultimately leads to the serialization issues
>>>>>> that I am seeing in this example.
>>>>>>
>>>
>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: More XSD -> EMF -> UML Issues [message #627539 is a reply to message #478351] Wed, 29 April 2009 21:49 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Ed,

The XML Name does transfer for property types stereotyped as
<<eReference>> in DocumentRoot (e.g. xMLNSPrefixMap and xSISchemaLocation)
but not for anything else...

Ed Merks wrote:

> John,

> That sucks especially given that UML extends EModelElement so that
> everything can have an EAnnotation...


> John T.E. Timm wrote:
>> Ed,
>>
>> Even with "Process All" selected it doesn't carry over the xml names
>> to the UML model.
>>
>> Ed Merks wrote:
>>
>>> John,
>>
>>> Probably there's an option to preserve the EAnnotations?
>>
>>
>>> John T.E. Timm wrote:
>>>> Actually a clarification on this:
>>>>
>>>> It looks like Writer.books is fine as is Library.books and
>>>> Library.writers. They start out with Containment set in the Ecore
>>>> which translates to Composition in the UML which translates back to
>>>> Containment in the Ecore. So basically, the problem is in marking
>>>> the composition as "derived" for the special case of
>>>> DocumentRoot.library.
>>>>
>>>> On another side note, none of the xmlNames are transferred through
>>>> from Ecore to properties of the eClass, eAttribute, and eReference
>>>> stereotypes.
>>>>
>>>> JT
>>>>
>>>> John T.E. Timm wrote:
>>>>
>>>>> Though I do like the ability to add OCL directly to schema via
>>>>> annotations, I have a requirement to be in UML as there are
>>>>> existing models that will reference these models and will be part
>>>>> of the UML->EMF conversion process to get to code generation with OCL.
>>>>
>>>>> Some of the other references (e.g. Writer.books) have "Composition"
>>>>> set in the UML model but this does not translate to having
>>>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>>>> study further what actually triggers Containment to be set. In the
>>>>> UML2EcoreConverter it looks like property.isComposite is called to
>>>>> determine some of the behavior, so I would figure that all of the
>>>>> associations in the UML model that are "Composition" should be
>>>>> transferred through which is clearly not the case.
>>>>
>>>>> JT
>>>>
>>>>> Ed Merks wrote:
>>>>
>>>>>> John,
>>>>
>>>>>> Probably the exporter should be taking into account that the
>>>>>> containment derivation is from a feature map rather than being
>>>>>> derived from another containment reference in which case it
>>>>>> denotes subsetting.
>>>>
>>>>>> Note that you should be able to add OCL constraints directly to
>>>>>> the XSD. To see how, just take an Ecore file that has the
>>>>>> constraints in the form you desire, export it to an XML Schema,
>>>>>> and have a look at how that Ecore EAnnotations are expressed as
>>>>>> XML Schema annotations...
>>>>
>>>>
>>>>>> John T.E. Timm wrote:
>>>>>>> I discovered that during the EMF->UML import process, the
>>>>>>> containment reference "library" in DocumentRoot is marked as
>>>>>>> "derived" in the UML model. This causes a problem during the
>>>>>>> UML->EMF import process. Apparently contaiment references marked
>>>>>>> as "derived" do not set the "Containment" property on the
>>>>>>> EReference which ultimately leads to the serialization issues
>>>>>>> that I am seeing in this example.
>>>>>>>
>>>>
>>>>
>>
>>
Re: More XSD -> EMF -> UML Issues [message #627544 is a reply to message #478352] Fri, 01 May 2009 20:45 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi John,

Please raise separate bugs on all the issues you are encountering. It
appears there are holes in the complete round trip story for converting from
XSD -> EMF -> UML and back.

- James.

"John T.E. Timm" <johntimm@us.ibm.com> wrote in message
news:c11e2f46ab0f6b35afa49ee4c19a6013$1@www.eclipse.org...
> Ed,
>
> The XML Name does transfer for property types stereotyped as
> <<eReference>> in DocumentRoot (e.g. xMLNSPrefixMap and xSISchemaLocation)
> but not for anything else...
>
> Ed Merks wrote:
>
>> John,
>
>> That sucks especially given that UML extends EModelElement so that
>> everything can have an EAnnotation...
>
>
>> John T.E. Timm wrote:
>>> Ed,
>>>
>>> Even with "Process All" selected it doesn't carry over the xml names to
>>> the UML model.
>>>
>>> Ed Merks wrote:
>>>
>>>> John,
>>>
>>>> Probably there's an option to preserve the EAnnotations?
>>>
>>>
>>>> John T.E. Timm wrote:
>>>>> Actually a clarification on this:
>>>>>
>>>>> It looks like Writer.books is fine as is Library.books and
>>>>> Library.writers. They start out with Containment set in the Ecore
>>>>> which translates to Composition in the UML which translates back to
>>>>> Containment in the Ecore. So basically, the problem is in marking the
>>>>> composition as "derived" for the special case of DocumentRoot.library.
>>>>>
>>>>> On another side note, none of the xmlNames are transferred through
>>>>> from Ecore to properties of the eClass, eAttribute, and eReference
>>>>> stereotypes.
>>>>>
>>>>> JT
>>>>>
>>>>> John T.E. Timm wrote:
>>>>>
>>>>>> Though I do like the ability to add OCL directly to schema via
>>>>>> annotations, I have a requirement to be in UML as there are existing
>>>>>> models that will reference these models and will be part of the
>>>>>> UML->EMF conversion process to get to code generation with OCL.
>>>>>
>>>>>> Some of the other references (e.g. Writer.books) have "Composition"
>>>>>> set in the UML model but this does not translate to having
>>>>>> "Containment" set in the EMF when going from UML->EMF. I have to
>>>>>> study further what actually triggers Containment to be set. In the
>>>>>> UML2EcoreConverter it looks like property.isComposite is called to
>>>>>> determine some of the behavior, so I would figure that all of the
>>>>>> associations in the UML model that are "Composition" should be
>>>>>> transferred through which is clearly not the case.
>>>>>
>>>>>> JT
>>>>>
>>>>>> Ed Merks wrote:
>>>>>
>>>>>>> John,
>>>>>
>>>>>>> Probably the exporter should be taking into account that the
>>>>>>> containment derivation is from a feature map rather than being
>>>>>>> derived from another containment reference in which case it denotes
>>>>>>> subsetting.
>>>>>
>>>>>>> Note that you should be able to add OCL constraints directly to the
>>>>>>> XSD. To see how, just take an Ecore file that has the constraints
>>>>>>> in the form you desire, export it to an XML Schema, and have a look
>>>>>>> at how that Ecore EAnnotations are expressed as XML Schema
>>>>>>> annotations...
>>>>>
>>>>>
>>>>>>> John T.E. Timm wrote:
>>>>>>>> I discovered that during the EMF->UML import process, the
>>>>>>>> containment reference "library" in DocumentRoot is marked as
>>>>>>>> "derived" in the UML model. This causes a problem during the
>>>>>>>> UML->EMF import process. Apparently contaiment references marked as
>>>>>>>> "derived" do not set the "Containment" property on the EReference
>>>>>>>> which ultimately leads to the serialization issues that I am seeing
>>>>>>>> in this example.
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Previous Topic:Importing XMI in Eclipse Modelling Tools
Next Topic:[Announce] MDT UML2 3.0.0M7 is available
Goto Forum:
  


Current Time: Sun Aug 14 19:46:27 GMT 2022

Powered by FUDForum. Page generated in 0.03095 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top