Home » Modeling » EMF » Can't Steer EType from XSD: Type vs Type1 vs Type2 Problems(EMF from XSD)
|
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 |
Ed Merks 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 |
Brandon Lewis 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 #1496687 is a reply to message #1496050] |
Wed, 03 December 2014 07:28 |
Ed Merks 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/
|
|
| | |
Goto Forum:
Current Time: Thu Mar 28 21:09:12 GMT 2024
Powered by FUDForum. Page generated in 0.04970 seconds
|