Home » Modeling » UML2 » More XSD -> EMF -> UML Issues
| More XSD -> EMF -> UML Issues [message #478342] |
Tue, 28 April 2009 20:13  |
 John T.E. Timm
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 #478348 is a reply to message #478347] |
Wed, 29 April 2009 16:52  |
John T.E. Timm
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 |
Ed Merks
Messages: 33133
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 |
John T.E. Timm
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 |
Ed Merks
Messages: 33133
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 |
John T.E. Timm
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 |
james bruck
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 #627533 is a reply to message #478345] |
Wed, 29 April 2009 10:07 |
Ed Merks
Messages: 33133
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 #627535 is a reply to message #478347] |
Wed, 29 April 2009 16:52 |
John T.E. Timm
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 |
Ed Merks
Messages: 33133
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 |
John T.E. Timm
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 |
Ed Merks
Messages: 33133
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 |
John T.E. Timm
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 |
james bruck
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.
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 11:26:12 GMT 2024
Powered by FUDForum. Page generated in 0.02785 seconds |
] 
Search
Help
Register
Login
Home
