| XSDRedefinableComponent [message #76823] |
Fri, 09 January 2009 04:22  |
Eclipse User |
|
|
|
Having a look into XSD.ecore in org.eclipse.xsd_2.4.1.v200808251517.jar,
I see that the abstract EClass "XSDRedefinableComponent" has the
abstract ESuperType "XSDRedefineContent".
All non abstract EClasses which have ESuperType
"XSDRedefinableComponent", e.g. "XSDAttributeGroupDefinition",
"XSDModelGroupDefinition", "XSDTypeDefinition" also have ESuperType
"XSDRedefineContent". The EClass "XSDRedefinableComponent" is never
inherited without also inherting "XSDRedefineContent".
So, the EClass "XSDRedefineContent" is inherited directly AND indirectly.
Is there any special reason for such a - I tend to say bad - modeling?
Will the direct inheritance be removed in later versions?
Regards,
Joachim Back
|
|
|
| Re: XSDRedefinableComponent [message #76839 is a reply to message #76823] |
Fri, 09 January 2009 09:16  |
| Eclipse User |
|
|
|
Joachim,
Comments below.
Joachim Back wrote:
> Having a look into XSD.ecore in
> org.eclipse.xsd_2.4.1.v200808251517.jar, I see that the abstract
> EClass "XSDRedefinableComponent" has the abstract ESuperType
> "XSDRedefineContent".
>
> All non abstract EClasses which have ESuperType
> "XSDRedefinableComponent", e.g. "XSDAttributeGroupDefinition",
> "XSDModelGroupDefinition", "XSDTypeDefinition" also have ESuperType
> "XSDRedefineContent". The EClass "XSDRedefinableComponent" is never
> inherited without also inherting "XSDRedefineContent".
>
> So, the EClass "XSDRedefineContent" is inherited directly AND indirectly.
>
> Is there any special reason for such a - I tend to say bad - modeling?
> Will the direct inheritance be removed in later versions?
I suppose that making the diagrams pettier at the expense of redundant
inheritance in the model isn't an ideal trade-off. I'll have to add
redefineable component to the concrete containment diagram to make that
complete. When I convert to using Ecore Tools instead of Rose, I could
definitely do that. Please open a bugzilla enhancement request to track
the issue. Redoing the diagrams with Ecore Tools will be a lot of work
and isn't a priority mind you...
>
> Regards,
> Joachim Back
|
|
|
| Re: XSDRedefinableComponent [message #603600 is a reply to message #76823] |
Fri, 09 January 2009 09:16 |
| Eclipse User |
|
|
|
Joachim,
Comments below.
Joachim Back wrote:
> Having a look into XSD.ecore in
> org.eclipse.xsd_2.4.1.v200808251517.jar, I see that the abstract
> EClass "XSDRedefinableComponent" has the abstract ESuperType
> "XSDRedefineContent".
>
> All non abstract EClasses which have ESuperType
> "XSDRedefinableComponent", e.g. "XSDAttributeGroupDefinition",
> "XSDModelGroupDefinition", "XSDTypeDefinition" also have ESuperType
> "XSDRedefineContent". The EClass "XSDRedefinableComponent" is never
> inherited without also inherting "XSDRedefineContent".
>
> So, the EClass "XSDRedefineContent" is inherited directly AND indirectly.
>
> Is there any special reason for such a - I tend to say bad - modeling?
> Will the direct inheritance be removed in later versions?
I suppose that making the diagrams pettier at the expense of redundant
inheritance in the model isn't an ideal trade-off. I'll have to add
redefineable component to the concrete containment diagram to make that
complete. When I convert to using Ecore Tools instead of Rose, I could
definitely do that. Please open a bugzilla enhancement request to track
the issue. Redoing the diagrams with Ecore Tools will be a lot of work
and isn't a priority mind you...
>
> Regards,
> Joachim Back
|
|
|
Powered by
FUDForum. Page generated in 0.02986 seconds
Home