Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » complexType mapped to EDataType
complexType mapped to EDataType [message #72238] Tue, 01 May 2007 07:04 Go to next message
Matthew Rawlings is currently offline Matthew Rawlings
Messages: 39
Registered: July 2009
Member
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. This is complex
because it has more than one Property. It does not make sense to map this
to a Class when it is clearly a Data Type by definition. 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?

I do not wish to make a private enhancement as I publish my XSD with eCore
annotations in them.
Re: complexType mapped to EDataType [message #72256 is a reply to message #72238] Tue, 01 May 2007 07:31 Go to previous messageGo to next message
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 #72273 is a reply to message #72256] Wed, 02 May 2007 08:32 Go to previous messageGo to next message
Matthew Rawlings is currently offline Matthew Rawlings
Messages: 39
Registered: July 2009
Member
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 #72292 is a reply to message #72273] Wed, 02 May 2007 08:48 Go to previous messageGo to next message
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 #72366 is a reply to message #72292] Thu, 03 May 2007 06:14 Go to previous messageGo to next message
Matthew Rawlings is currently offline Matthew Rawlings
Messages: 39
Registered: July 2009
Member
"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 #72384 is a reply to message #72366] Thu, 03 May 2007 07:40 Go to previous message
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 07:31 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26000
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?
Re: complexType mapped to EDataType [message #602347 is a reply to message #72256] Wed, 02 May 2007 08:32 Go to previous message
Matthew Rawlings is currently offline Matthew Rawlings
Messages: 39
Registered: July 2009
Member
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 #602350 is a reply to message #72273] Wed, 02 May 2007 08:48 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26000
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?
>
>
>
Re: complexType mapped to EDataType [message #602367 is a reply to message #72292] Thu, 03 May 2007 06:14 Go to previous message
Matthew Rawlings is currently offline Matthew Rawlings
Messages: 39
Registered: July 2009
Member
"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 #602373 is a reply to message #72366] Thu, 03 May 2007 07:40 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26000
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.
>
Previous Topic:Refreshing an eCore model when a schema changes
Next Topic:XSDSchema Loading
Goto Forum:
  


Current Time: Sat Aug 23 05:43:57 EDT 2014

Powered by FUDForum. Page generated in 0.02031 seconds