Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems(EMF from XSD)
icon9.gif  Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1495919] Tue, 02 December 2014 16:28 Go to next message
Brandon Lewis is currently offline Brandon LewisFriend
Messages: 268
Registered: May 2012
Senior Member
I have a model that comes from an industry standard XSD. I have converted it to EMF. Recently, I fixed a problem we had that modified the content of the XSD.

Unfortunately, now that I've Reloaded my model from the XSD, I have over 160 differences in the resulting ecore model.

One of the seemingly superficial differences is shown in this example.

I have something called an AddressBlock which contains a BaseAddress. That BaseAddress used to be of BaseAddressType, but now is of BaseAddressType1.

Why is this seemingly superficial, because when I look at the ecore model of BaseAddressType and BaseAddressType1, they have what appears to be the exact same content. So I assume they differ only in what other objects have containment references to them.

160 such changes are going to get me in trouble with my developers and causes other error prone issues.

I thought I could annotate my XSD with things like ecore:name="BaseAddress" and solve this issue, but for the last 2 hours I've put every ecore:<thingy>="" I can think of and I just can't get EMF to honor my EType Class name request.

Headaches... How can I properly steer EMF in this regard? Right now my only option seems to hand modify the ecore model where I see easy resolutions. But that's obviously going to break the next time I have to re-gen the model.

Re: Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1495962 is a reply to message #1495919] Tue, 02 December 2014 17:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Brandon,

Comments below.

On 02/12/2014 5:28 PM, Brandon Lewis wrote:
> I have a model that comes from an industry standard XSD. I have
> converted it to EMF. Recently, I fixed a problem we had that modified
> the content of the XSD.
>
> Unfortunately, now that I've Reloaded my model from the XSD, I have
> over 160 differences in the resulting ecore model.
Ouch.
>
> One of the seemingly superficial differences is shown in this example.
> I have something called an AddressBlock which contains a BaseAddress.
> That BaseAddress used to be of BaseAddressType, but now is of
> BaseAddressType1.
> Why is this seemingly superficial, because when I look at the ecore
> model of BaseAddressType and BaseAddressType1, they have what appears
> to be the exact same content. So I assume they differ only in what
> other objects have containment references to them.
Although you don't mention it, such induced names generally are the
result of anonymous types....
>
> 160 such changes are going to get me in trouble with my developers and
> causes other error prone issues.
Definitely. You need stable names in the APIs.
>
> I thought I could annotate my XSD with things like
> ecore:name="BaseAddress" and solve this issue,
Yes, that's definitely the case.
> but for the last 2 hours I've put every ecore:<thingy>="" I can think
> of and I just can't get EMF to honor my EType Class name request.
It's hard to comment without a specific example. I assume you've
properly declared the xmlns:ecore... And, as I suggested, the problem
will step from anonymous types so did you try to give names to things
that don't actually have a name="..." in the schema itself.
>
> Headaches... How can I properly steer EMF in this regard? Right now
> my only option seems to hand modify the ecore model where I see easy
> resolutions.
No, that's a permanent headache. Better to annotate the schema.
Generally you should look for the elements and attributes that have
anonymous types and give those nicer names.
> But that's obviously going to break the next time I have to re-gen the
> model.
If you can give a bit more concrete information about what you tried,
i.e., show me what you put in the root of the xml to declare the
namespace and show me an example of where you put an ecore:name
annotation that doesn't seem to affect the result the way you'd expect
and I'll try to give you pointers.
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1496050 is a reply to message #1495962] Tue, 02 December 2014 18:48 Go to previous messageGo to next message
Brandon Lewis is currently offline Brandon LewisFriend
Messages: 268
Registered: May 2012
Senior Member
Thank you for looking at this Ed!

At the root of the two XML files where I see the element baseAddress defined, I have this:

<xs:schema xmlns:spirit="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" targetNamespace="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009" elementFormDefault="qualified" attributeFormDefault="qualified">

In the first schema, memoryMap.xsd, I see baseAddress declared as an element and then referenced elsewhere in a sequence. Here you can see I am trying to force this to be declare as BaseAddresssType by EMF. (and in this example, the reparsing of the schema has resulted in a change from this being called BaseAddressType to BaseAddressType1 - which will break our code base)

<xs:element name="baseAddress" ecore:name="BaseAddress">
<xs:annotation>
<xs:documentation>Base of an address block, bank, subspace map or address space. Expressed as the number of addressable units from the containing memoryMap or localMemoryMap.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="spirit:scaledNonNegativeInteger">
<xs:attributeGroup ref="spirit:long.att"/>
<xs:attribute ref="spirit:prompt" default="Base Address:"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

And then the later reference in the same file:

<xs:group name="addressSpecifier">
<xs:annotation>
<xs:documentation>This group of elements describes an absolute or relative address of an address block in a memory map.

Note that this is a group, not an element. It does not appear in the XML, but its contents may.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="spirit:baseAddress"/>
</xs:sequence>
</xs:group>


Now in a different schema called busInterface.xsd, I have the same XML root as listed about - i.e. the ecore namespace is included.

Here is where I think the anonymous class is being specified in the schema. I'm sorry this snippet is quite long, but I've removed the closing tags.

(If it is not readable, the most important line would be:

<xs:element name="baseAddress" minOccurs="0" ecore:name="AddressSpaceRefBaseAddress">
)

<xs:group name="interfaceMode">
<xs:annotation>
<xs:documentation>Group of the different modes a busInterface can take on in a component</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="master">
<xs:annotation>
<xs:documentation>If this element is present, the bus interface can serve as a master. This element encapsulates additional information related to its role as master.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="addressSpaceRef" minOccurs="0">
<xs:annotation>
<xs:documentation>If this master connects to an addressable bus, this element references the address space it maps to.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="spirit:addrSpaceRefType">
<xs:sequence>
<xs:annotation>
<xs:documentation>If the master's mapping to the physical address space is not zero based, the baseAddress element may be used to indicate the offset. If not specified the offset is 0. The baseAddress is in units of the addressSpace addressUnitBits</xs:documentation>
</xs:annotation>
<xs:element name="baseAddress" minOccurs="0" ecore:name="AddressSpaceRefBaseAddress">
<xs:annotation>
<xs:documentation>Base of an address space.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="spirit:scaledInteger">
<xs:attributeGroup ref="spirit:long.att"/>
<xs:attribute ref="spirit:prompt" default="Base Address:"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>



With those changes, I am Right Clicking and asking Eclipse to Reload the genmodel from the XML schema (with the current genmodel and ecore file being present in my workspace)

I was hoping to see a new Class declared in my ecore file called "AddressSpaceRefBaseAddress" in an attempt to make it unique from the other 'BaseAddress', but that doesn't happen and instead is AddressSpaceRef class is referencing the BaseAddressType (used to be BaseAddressType1).
Re: Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1496066 is a reply to message #1496050] Tue, 02 December 2014 19:05 Go to previous messageGo to next message
Brandon Lewis is currently offline Brandon LewisFriend
Messages: 268
Registered: May 2012
Senior Member
And if I could change the BaseAddress Class within the addressSpaceRef back to BaseAddressType1 that would be great, but it appears the "Type1" added suffix isn't available to me in the ecore XSD annotations - so I'm content with fixing this correctly now and doing it in a way that preserves the most existing code possible (for instance we're not using addressSpaceRef yet, so giving that a new Class isn't the end of the world)
Re: Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1496687 is a reply to message #1496050] Wed, 03 December 2014 07:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Brandon,

Comments below.

On 02/12/2014 7:48 PM, Brandon Lewis wrote:
> Thank you for looking at this Ed!
>
> At the root of the two XML files where I see the element baseAddress
> defined, I have this:
>
> <xs:schema
> xmlns:spirit="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
> targetNamespace="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1685-2009"
> elementFormDefault="qualified" attributeFormDefault="qualified">
>
> In the first schema, memoryMap.xsd, I see baseAddress declared as an
> element and then referenced elsewhere in a sequence. Here you can see
> I am trying to force this to be declare as BaseAddresssType by EMF.
> (and in this example, the reparsing of the schema has resulted in a
> change from this being called BaseAddressType to BaseAddressType1 -
> which will break our code base)
>
> <xs:element name="baseAddress" ecore:name="BaseAddress">
This annotation is worse than pointless because elements map to
structural features and they should have a lower camel case name.
> <xs:annotation>
> <xs:documentation>Base of an address block, bank, subspace
> map or address space. Expressed as the number of addressable units
> from the containing memoryMap or localMemoryMap.</xs:documentation>
> </xs:annotation>
> <xs:complexType>
This is the anonymous complex type and will be assigned a name
baseAddress_._type, i.e., the name of the element and the word type.
That will be mangled into the name BaseAddressType, and if there is more
than one such classifier, that they will be assigned numbers like 1, 2,
3 rather arbitrarily. This is the place to add an ecore:name
annotation to determine a nice name.
> <xs:simpleContent>
> <xs:extension base="spirit:scaledNonNegativeInteger">
> <xs:attributeGroup ref="spirit:long.att"/>
> <xs:attribute ref="spirit:prompt" default="Base
> Address:"/>
> </xs:extension>
> </xs:simpleContent>
> </xs:complexType>
> </xs:element>
>
> And then the later reference in the same file:
>
> <xs:group name="addressSpecifier">
> <xs:annotation>
> <xs:documentation>This group of elements describes an
> absolute or relative address of an address block in a memory map.
>
> Note that this is a group, not an element. It does not appear in the
> XML, but its contents may.</xs:documentation>
> </xs:annotation>
> <xs:sequence>
> <xs:element ref="spirit:baseAddress"/>
> </xs:sequence>
> </xs:group>
>
>
> Now in a different schema called busInterface.xsd, I have the same XML
> root as listed about - i.e. the ecore namespace is included.
>
> Here is where I think the anonymous class is being specified in the
> schema. I'm sorry this snippet is quite long, but I've removed the
> closing tags.
>
> (If it is not readable, the most important line would be:
>
> <xs:element name="baseAddress" minOccurs="0"
> ecore:name="AddressSpaceRefBaseAddress">
> )
>
> <xs:group name="interfaceMode">
> <xs:annotation>
> <xs:documentation>Group of the different modes a
> busInterface can take on in a component</xs:documentation>
> </xs:annotation>
> <xs:choice>
> <xs:element name="master">
> <xs:annotation>
> <xs:documentation>If this element is present, the
> bus interface can serve as a master. This element encapsulates
> additional information related to its role as master.</xs:documentation>
> </xs:annotation>
> <xs:complexType>
> <xs:sequence>
> <xs:element name="addressSpaceRef" minOccurs="0">
> <xs:annotation>
> <xs:documentation>If this master
> connects to an addressable bus, this element references the address
> space it maps to.</xs:documentation>
> </xs:annotation>
> <xs:complexType>
> <xs:complexContent>
> <xs:extension
> base="spirit:addrSpaceRefType">
> <xs:sequence>
> <xs:annotation>
> <xs:documentation>If the master's mapping to the physical address
> space is not zero based, the baseAddress element may be used to
> indicate the offset. If not specified the offset is 0. The baseAddress
> is in units of the addressSpace addressUnitBits</xs:documentation>
> </xs:annotation>
> <xs:element
> name="baseAddress" minOccurs="0" ecore:name="AddressSpaceRefBaseAddress">
> <xs:annotation>
> <xs:documentation>Base of an address space.</xs:documentation>
> </xs:annotation>
> <xs:complexType>
This is where you should add an annotation. A feature name of
"baseAddress" would seem fine and natural, so don't change name. Just
change the name of this type.
> <xs:simpleContent>
> <xs:extension base="spirit:scaledInteger">
> <xs:attributeGroup ref="spirit:long.att"/>
> <xs:attribute ref="spirit:prompt" default="Base Address:"/>
> </xs:extension>
> </xs:simpleContent>
> </xs:complexType>
> </xs:element>
>
>
>
> With those changes, I am Right Clicking and asking Eclipse to Reload
> the genmodel from the XML schema (with the current genmodel and ecore
> file being present in my workspace)
>
> I was hoping to see a new Class declared in my ecore file called
> "AddressSpaceRefBaseAddress" in an attempt to make it unique from the
> other 'BaseAddress', but that doesn't happen and instead is
> AddressSpaceRef class is referencing the BaseAddressType (used to be
> BaseAddressType1).
Yes, I mentioned in my earlier post that anonymous types are involved
and that you should focus on given those specific names....


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1496694 is a reply to message #1496066] Wed, 03 December 2014 07:30 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Brandon,

With annotations on the anonymous types you should be able to give them
exactly the name you want and you should be able to preserve exactly the
names (for both features and classifiers) that were used before.

On 02/12/2014 8:05 PM, Brandon Lewis wrote:
> And if I could change the BaseAddress Class within the addressSpaceRef
> back to BaseAddressType1 that would be great, but it appears the
> "Type1" added suffix isn't available to me in the ecore XSD
> annotations - so I'm content with fixing this correctly now and doing
> it in a way that preserves the most existing code possible (for
> instance we're not using addressSpaceRef yet, so giving that a new
> Class isn't the end of the world)


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems [message #1500226 is a reply to message #1496694] Fri, 05 December 2014 20:10 Go to previous message
Brandon Lewis is currently offline Brandon LewisFriend
Messages: 268
Registered: May 2012
Senior Member
Thank you very much Ed. That was very helpful and I've been able to make progress with your help.
Previous Topic:How to serialze intrinsic ids as attributes?
Next Topic:[Xcore] [Texo] NPE exception occurring whenever typing in editor
Goto Forum:
  


Current Time: Thu Mar 28 21:09:12 GMT 2024

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

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

Back to the top