|
| Re: complexType mapped to EDataType [message #72256 is a reply to message #72238] |
Tue, 01 May 2007 11:31   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Matthew,
Comments below.
Matthew Rawlings wrote:
> I would like to map some of my complexType to EDataType.
> I understand the current mapping and annotations and would like to be
> able to add an annotation to some of xsd:complexType to map them to
> EDataType instead of EClass. I would also like to be able to add
> annotations to some of my xsd:simpleType to map them to EClass instead
> of EDataType.
>
> Below is an example of a UN/CEFACT CCTS complex data type "Money".
> This is a data type because it lacks identity and behaviour.
Yet isn't not a simple type and it has complex internal structure that
can change.
> This is complex because it has more than one Property.
A lot of information can be encoded in a simple data type. Look at how
many "fields" a dateTime has.
> It does not make sense to map this to a Class when it is clearly a
> Data Type by definition.
I think it's not so cut and dry to say it simply doesn't make sense to
map this to an EClass. It certainly makes reasonable sense and works
well that way. What specific problem is solved by making it not be an
EClass?
> I added a proposed eCore annotation of "ecore:Classifier" to the
> complexType definition.
>
> <xsd:complexType name="Money" abstract="false" mixed="false"
> ecore:classifier="EDataType">
> <xsd:sequence>
> <xsd:element name="currencyId" type="IdentifierDataType"/>
> <xsd:element name="amount">
> <xsd:simpleType>
> <xsd:restriction base="ValueDataType">
> <xsd:minExclusive value="0"/>
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
>
> My question is, would an additional annotation of eCore:classifier =
> EClass | EDataType for xsd:complexType and xsd:simpleType be a good
> solution, and would it be accepted as either an enhancement or
> contribution?
It's not as simple as just producing the Ecore model you want.
EDataTypes are always serializeable by virtue of having createFromString
and convertToString methods in XyzFactoryImpl. So these could need some
type of special handling that says, even though this is a data type,
serialize as an element with nested elements. How will the system know
what the nested elements are if we don't know this by virtue of the
instance being an EClass with features?
>
> I do not wish to make a private enhancement as I publish my XSD with
> eCore annotations in them.
>
>
Contributions are certainly welcome, but they need to fit in with the
overall architecture and defining an EDataType that must be serialized
like an EClass with internal structure doesn't fit well at all with how
serialization currently works, so that problem needs to be solved as
well. There are also issues with changes to the internal structure not
producing notifications such that a change recorder will work properly.
Once you define this as a data type and the instance can be shared
across many uses, you run into the issue that changing the value will
indirectly affect all the attributes that refer to that shared
instance. So the question of what problem are we solve while
introducing all these new problems really needs a very solid answer.
Mapping a simple type to an EClass also has problems (you can't express
xsi:type for an attribute using that type when a derived instance is
substituted) and begs the question, why isn't it modeled as complex type
with simple content if the full generality of an EClass is actually needed?
|
|
|
|
| Re: complexType mapped to EDataType [message #72292 is a reply to message #72273] |
Wed, 02 May 2007 12:48 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Matthew,
Well, Ecore isn't UML and so the concepts don't necessarily transfer
over. Most EClasses don't specify operations and hence don't specify
behavior, so that only leaves identity as a significant issue. Certainly
the way this is modeled in schema implies that a structured element is
needed to represent the data and presumably elements have identity. How
does having identity when you don't want it cause a problem?
Yes, I think EDataType is a better match for PrimitiveDataType but I've
seen some recent discussions on the UML2 newsgroup that makes it clear
that no everyone agrees on exactly what's a primitive data type.
Matthew Rawlings wrote:
> Q1: "What specific problem is solved by making it not be an EClass?"
>
> A1: The main problem this solves is clarity in the model. A CCTS Money Core
> Data Type is in UML terms a UML Data Type - it lacks identity, and it lacks
> behaviour. The lack of identity and behaviour is why it is not a Class.
> There is no mechanism to distinguish different sub-types of Classifier
> within XML Schema, so this information is lost.
>
> The XSD schema is pre-existing, so there is no option to change the XSD
> schema.
>
> How closely does the definition of EDataType match the UML DataType? The
> reason I ask is because the implementation requirement to have
> createFromString and convertToString methods, does this imply that EDataType
> is a better match to the UML PrimitiveDataType?
>
>
>
|
|
|
|
| Re: complexType mapped to EDataType [message #72384 is a reply to message #72366] |
Thu, 03 May 2007 11:40 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Matthew,
That sounds like a multi-year exercise and given my understanding of the
issues involved in mapping XSD to Ecore, I can't imagine such a mapping
being functionally complete without dealing with hard issues such as
substitution groups, wildcards, complex particle structure, and so on.
Some of these things required changes to Ecore itself, so I wouldn't
hold out a lot of hope that you will arrive at a solution that's more
functionally complete than the one EMF already provides anytime soon.
And the mapping in the other direction is even worse, given that XML
Schema is totally incapable of expressing multiple inheritance.
Matthew Rawlings wrote:
> "I think EDataType is a better match for PrimitiveDataType" - I agree,
> I believe this is the key to understanding the issue.
>
> At this point I believe the best thing I can do is return to the OMG
> XMI team to see if we can get some agreement, based on my examples, on
> the XMI mapping for XSD to EMOF in this area.
>
|
|
|
| Re: complexType mapped to EDataType [message #602344 is a reply to message #72238] |
Tue, 01 May 2007 11:31 |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Matthew,
Comments below.
Matthew Rawlings wrote:
> I would like to map some of my complexType to EDataType.
> I understand the current mapping and annotations and would like to be
> able to add an annotation to some of xsd:complexType to map them to
> EDataType instead of EClass. I would also like to be able to add
> annotations to some of my xsd:simpleType to map them to EClass instead
> of EDataType.
>
> Below is an example of a UN/CEFACT CCTS complex data type "Money".
> This is a data type because it lacks identity and behaviour.
Yet isn't not a simple type and it has complex internal structure that
can change.
> This is complex because it has more than one Property.
A lot of information can be encoded in a simple data type. Look at how
many "fields" a dateTime has.
> It does not make sense to map this to a Class when it is clearly a
> Data Type by definition.
I think it's not so cut and dry to say it simply doesn't make sense to
map this to an EClass. It certainly makes reasonable sense and works
well that way. What specific problem is solved by making it not be an
EClass?
> I added a proposed eCore annotation of "ecore:Classifier" to the
> complexType definition.
>
> <xsd:complexType name="Money" abstract="false" mixed="false"
> ecore:classifier="EDataType">
> <xsd:sequence>
> <xsd:element name="currencyId" type="IdentifierDataType"/>
> <xsd:element name="amount">
> <xsd:simpleType>
> <xsd:restriction base="ValueDataType">
> <xsd:minExclusive value="0"/>
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:element>
> </xsd:sequence>
> </xsd:complexType>
>
> My question is, would an additional annotation of eCore:classifier =
> EClass | EDataType for xsd:complexType and xsd:simpleType be a good
> solution, and would it be accepted as either an enhancement or
> contribution?
It's not as simple as just producing the Ecore model you want.
EDataTypes are always serializeable by virtue of having createFromString
and convertToString methods in XyzFactoryImpl. So these could need some
type of special handling that says, even though this is a data type,
serialize as an element with nested elements. How will the system know
what the nested elements are if we don't know this by virtue of the
instance being an EClass with features?
>
> I do not wish to make a private enhancement as I publish my XSD with
> eCore annotations in them.
>
>
Contributions are certainly welcome, but they need to fit in with the
overall architecture and defining an EDataType that must be serialized
like an EClass with internal structure doesn't fit well at all with how
serialization currently works, so that problem needs to be solved as
well. There are also issues with changes to the internal structure not
producing notifications such that a change recorder will work properly.
Once you define this as a data type and the instance can be shared
across many uses, you run into the issue that changing the value will
indirectly affect all the attributes that refer to that shared
instance. So the question of what problem are we solve while
introducing all these new problems really needs a very solid answer.
Mapping a simple type to an EClass also has problems (you can't express
xsi:type for an attribute using that type when a derived instance is
substituted) and begs the question, why isn't it modeled as complex type
with simple content if the full generality of an EClass is actually needed?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: complexType mapped to EDataType [message #602350 is a reply to message #72273] |
Wed, 02 May 2007 12:48 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Matthew,
Well, Ecore isn't UML and so the concepts don't necessarily transfer
over. Most EClasses don't specify operations and hence don't specify
behavior, so that only leaves identity as a significant issue. Certainly
the way this is modeled in schema implies that a structured element is
needed to represent the data and presumably elements have identity. How
does having identity when you don't want it cause a problem?
Yes, I think EDataType is a better match for PrimitiveDataType but I've
seen some recent discussions on the UML2 newsgroup that makes it clear
that no everyone agrees on exactly what's a primitive data type.
Matthew Rawlings wrote:
> Q1: "What specific problem is solved by making it not be an EClass?"
>
> A1: The main problem this solves is clarity in the model. A CCTS Money Core
> Data Type is in UML terms a UML Data Type - it lacks identity, and it lacks
> behaviour. The lack of identity and behaviour is why it is not a Class.
> There is no mechanism to distinguish different sub-types of Classifier
> within XML Schema, so this information is lost.
>
> The XSD schema is pre-existing, so there is no option to change the XSD
> schema.
>
> How closely does the definition of EDataType match the UML DataType? The
> reason I ask is because the implementation requirement to have
> createFromString and convertToString methods, does this imply that EDataType
> is a better match to the UML PrimitiveDataType?
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: complexType mapped to EDataType [message #602373 is a reply to message #72366] |
Thu, 03 May 2007 11:40 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Matthew,
That sounds like a multi-year exercise and given my understanding of the
issues involved in mapping XSD to Ecore, I can't imagine such a mapping
being functionally complete without dealing with hard issues such as
substitution groups, wildcards, complex particle structure, and so on.
Some of these things required changes to Ecore itself, so I wouldn't
hold out a lot of hope that you will arrive at a solution that's more
functionally complete than the one EMF already provides anytime soon.
And the mapping in the other direction is even worse, given that XML
Schema is totally incapable of expressing multiple inheritance.
Matthew Rawlings wrote:
> "I think EDataType is a better match for PrimitiveDataType" - I agree,
> I believe this is the key to understanding the issue.
>
> At this point I believe the best thing I can do is return to the OMG
> XMI team to see if we can get some agreement, based on my examples, on
> the XMI mapping for XSD to EMOF in this area.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03984 seconds
] 
Search
Help
Register
Login
Home
