Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype
XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1694339] Mon, 04 May 2015 15:04 Go to next message
Philippe Favrais is currently offline Philippe FavraisFriend
Messages: 23
Registered: April 2011
Junior Member
In an XSD i have xsd:element declaration which have not type defined e.g.:FR_SM_CH and other having conplex type e.g. : FR_TP_CH
See the example
<xs:sequence>
<xs:element name="FR_SM_CH" minOccurs="0"/>
<xs:element name="FR_TP_CH" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="FR_TP_CHANNEL" minOccurs="0" maxOccurs="unbounded">

During the Ecore genration XsdEcoreBuilder maps as followning
<eStructuralFeatures xsi:type="ecore:EReference" name="fRSMCH" eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject"
containment="true" resolveProxies="false">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="element"/>
<details key="name" value="FR_SM_CH"/>
<details key="namespace" value="##targetNamespace"/>
</eAnnotations>
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="fRTPCH" eType="#//FRTPCHType"
containment="true" resolveProxies="false">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="element"/>
<details key="name" value="FR_TP_CH"/>
<details key="namespace" value="##targetNamespace"/>
</eAnnotations>
</eStructuralFeatures>

Now when i use the Using the EcoreREflective Editor, the popup menu Create NewChild is populated correctly for the XSD Element having a complex type but for the xsd:element having no type,
the corresponding subMenu is repeated many time while i would expect it only one

I don't know why? Does anybody already encountered that problem ?

Thank you in advance
Philippe

Report message to a moderator

Re: XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1694352 is a reply to message #1694339] Mon, 04 May 2015 15:59 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30350
Registered: July 2009
Senior Member
Philippe,

Comments below.


On 04/05/2015 5:04 PM, Philippe Favrais wrote:
> In an XSD i have xsd:element declaration which have not type defined
> e.g.:FR_SM_CH and other having conplex type e.g. : FR_TP_CH
> See the example
> <xs:sequence>
> <xs:element name="FR_SM_CH" minOccurs="0"/>
This implicitly has xsd:any as the type.
> <xs:element name="FR_TP_CH" minOccurs="0">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="FR_TP_CHANNEL" minOccurs="0"
> maxOccurs="unbounded">
>
> During the Ecore genration XsdEcoreBuilder maps as followning
> <eStructuralFeatures xsi:type="ecore:EReference" name="fRSMCH"
> eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject"
And xsd:anyType is mapped to EObject.
> containment="true" resolveProxies="false">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="element"/>
> <details key="name" value="FR_SM_CH"/>
> <details key="namespace" value="##targetNamespace"/>
> </eAnnotations>
> </eStructuralFeatures>
> <eStructuralFeatures xsi:type="ecore:EReference" name="fRTPCH"
> eType="#//FRTPCHType"
> containment="true" resolveProxies="false">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="element"/>
> <details key="name" value="FR_TP_CH"/>
> <details key="namespace" value="##targetNamespace"/>
> </eAnnotations>
> </eStructuralFeatures>
>
> Now when i use the Using the EcoreREflective Editor, the popup menu
> Create NewChild is populated correctly for the XSD Element having a
> complex type but for the xsd:element having no type, the corresponding
> subMenu is repeated many time while i would expect it only one
All EObjects are allowed, so all instances of all known EClasses will be
present; that could be a very very long list...
>
> I don't know why? Does anybody already encountered that problem ?
I'm not sure there is a problem; just your expectation doesn't match the
reality (that any type of object can appear for that element)...
>
> Thank you in advance
> Philippe

Report message to a moderator

Re: XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1694355 is a reply to message #1694352] Mon, 04 May 2015 16:31 Go to previous messageGo to next message
Philippe Favrais is currently offline Philippe FavraisFriend
Messages: 23
Registered: April 2011
Junior Member
Thank you Ed,
indeed it is a long list...
I see : element without type are interpreted as AnyType? Then, it proposes me all the global type.

To workaround that behavior, i am thinking to bind that element to a complex type so that XsdEcoreBuilder bind this element (feature) to a well defined type (class)
<xs:element name="FR_TRCV_CH" minOccurs="0">
<xs:complexType>
<xs:choice/>
</xs:complexType>
</xs:element>

Is it a solution that seems correct ?
Do you know how should i overwrite xsdEcoreBuilder to create such complex type for an existing Element ?

Report message to a moderator

Re: XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1694394 is a reply to message #1694355] Tue, 05 May 2015 05:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30350
Registered: July 2009
Senior Member
Philippe,

Comments below.

On 04/05/2015 6:31 PM, Philippe Favrais wrote:
> Thank you Ed,
> indeed it is a long list...
> I see : element without type are interpreted as AnyType? Then, it
> proposes me all the global type.
Exactly.
> To workaround that behavior, i am thinking to bind that element to a
> complex type so that XsdEcoreBuilder bind this element (feature) to a
> well defined type (class)
> <xs:element name="FR_TRCV_CH" minOccurs="0">
> <xs:complexType>
> <xs:choice/>
> </xs:complexType>
> </xs:element>
>
> Is it a solution that seems correct ?
Yes that would do the trick. Of course such an object is kind of
pointless because it doesn't carry any data, but then I'm not sure the
intent of the original schema... What is the point of this element if
not to carry arbitrary complex type instances?
> Do you know how should i overwrite xsdEcoreBuilder to create such
> complex type for an existing Element ?
>
If you're really intent on doing that, i.e.,I'm not sure the point/goal;
you can of course change the schema exactly as you've show it. Of
course you can use the debugger to see how your example above is
processed and what's produced for it verses the original form, i.e.,
look at what happens in
org.eclipse.xsd.ecore.XSDEcoreBuilder.createFeature(EClass,
XSDElementDeclaration, String, XSDComponent, int, int).

Report message to a moderator

Re: XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1697082 is a reply to message #1694394] Mon, 01 June 2015 13:15 Go to previous messageGo to next message
Philippe Favrais is currently offline Philippe FavraisFriend
Messages: 23
Registered: April 2011
Junior Member
Hello Ed,

I come back to my problem with XSD which i let for a while.
In fact now i would like to identify all elements in my XSD files which have neither simple type nor complex type definition e.g. : <xs:element name="FR_SM_CH" minOccurs="0"/> : yes it doesn't carry any data
How can i find such elements ?
During my test, i expected that the returned type of such element would have been null !
XSDTypeDefinition elementTypeDefinition = getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration)
here is what i get : org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl@415262a0 (element: [xs:complexType: null]) (name: anyType, targetNamespace: http://www.w3.org/2001/XMLSchema) (derivationMethod: <unset>, final: [], abstract: <unset>, contentTypeCategory: elementOnly, prohibitedSubstitutions: [extension, restriction], lexicalFinal: null, block: null, mixed: true)

Philippe

Report message to a moderator

Re: XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1697086 is a reply to message #1697082] Mon, 01 June 2015 13:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30350
Registered: July 2009
Senior Member
Philippe,

Comments below.

On 01/06/2015 3:15 PM, Philippe Favrais wrote:
> Hello Ed,
>
> I come back to my problem with XSD which i let for a while.
> In fact now i would like to identify all elements in my XSD files
> which have neither simple type nor complex type definition e.g. :
> <xs:element name="FR_SM_CH" minOccurs="0"/> : yes it doesn't carry any
> data
> How can i find such elements ?
> During my test, i expected that the returned type of such element
> would have been null ! XSDTypeDefinition elementTypeDefinition =
> getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration)
> here is what i get :
> mailto:org.eclipse.xsd.impl.XSDComplexTypeDefinitionImpl@415262a0
> (element: [xs:complexType: null]) (name: anyType, targetNamespace:
> http://www.w3.org/2001/XMLSchema) (derivationMethod: <unset>, final:
> [], abstract: <unset>, contentTypeCategory: elementOnly,
> prohibitedSubstitutions: [extension, restriction], lexicalFinal: null,
> block: null, mixed: true)
Yes, the absence of a type attribute in the concrete model for an
element declaration is defined in the specification to be equivalent to
specifying "xsd:anyType" explicitly.

XSDUtil.isAnyType can be used to check if a type represents the anyType...
>
> Philippe
>
>

Report message to a moderator

Re: XSDEcoreBuilder / EcoreRefletive Editor : Strange behavior with xsd:element without typetype [message #1697117 is a reply to message #1697086] Mon, 01 June 2015 17:04 Go to previous message
Philippe Favrais is currently offline Philippe FavraisFriend
Messages: 23
Registered: April 2011
Junior Member
Indeed, isAnyType() is what i need, thanks Ed.
Now i am trying to set a complexType to such Element <xs:element name="CHILD1" minOccurs="0"/>.

However after having created in the Ecore, i remarked that the "Name" (eAnnotation) seems not the way it should
It seems to work, but i can't explain why the name is not formatted like the others: I fear i do not set it correctly. Is their any Api that allow to do it correctly ?

<eClassifiers xsi:type="ecore:EClass" name="CHILD1type">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="CHILD1type"/> <-- wrong name
<details key="kind" value="empty"/>
</eAnnotations>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="CHILD3Type">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="name" value="CHILD3_._type"/> <-- correct name
<details key="kind" value="empty"/>
</eAnnotations>
</eClassifiers>

Report message to a moderator

Previous Topic:How to register ecore file and look up for already registered ones in Eclipse
Next Topic:EcoreUtil.generateUUID()
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sat Aug 17 17:15:16 GMT 2019

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly