Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Ecore mapping of simple types
Ecore mapping of simple types [message #28914] Wed, 10 September 2003 15:32 Go to next message
Eclipse UserFriend
Originally posted by: ihc.sas-glas.mottmac.com

I'm having some trouble relating what the new "EMF" book says with the
behaviour I see from reading and executing the code.

For XML Schema simple types that are not included in the table on p.140
(or derived from these), the book says we should get an EDataType with
name equal to the XML Schema type, and instanceClassName of
java.lang.String.

This would be fine for me. But in tracing through for an xsd:attribute of
type xsd:integer, unless I am looking in the wrong place I am getting a
plain EString - no trace of the "integer" name.

I'm looking at XSDEcoreBuilder.getEClassifier(XSDTypeDefinition, boolean)
which, as expected, fails to find a direct mapping for "integer", so it
looks for a mapping for the base type "decimal", which also fails as
expected, and so it assigns an EString with name = "EString". As far as I
can see the name is never set to "integer" as the text on p.140 suggests.

Which is wrong - me, the book or the code?

Ian
Re: Ecore mapping of simple types [message #29135 is a reply to message #28914] Wed, 10 September 2003 18:25 Go to previous messageGo to next message
David Steinberg is currently offline David SteinbergFriend
Messages: 489
Registered: July 2009
Senior Member
Ian Cornwell wrote:
> For XML Schema simple types that are not included in the table on p.140
> (or derived from these), the book says we should get an EDataType with
> name equal to the XML Schema type, and instanceClassName of
> java.lang.String.
> ...
> Which is wrong - me, the book or the code?

Hi Ian,

Unfortunately, the book.

The book's companion web site (http://www.aw.com/budinsky/) includes an
Errata ( http://wps.aw.com/aw_budinsky_eclipsemod_1/0,7999,967283-,00 .html).
You'll notice that this problem comes up twice: on page 82 and on page 140.

The book describes the way it used to work, and then the current, simpler
approach was adopted later on in the publishing cycle. The text was never
updated to reflect the change.

Please continue refer to the Errata when things don't seem quite right, and
do let us know if you find any other problems that we haven't caught yet, so
that we can keep it up to date.

Thanks,
Dave
Re: Ecore mapping of simple types [message #29248 is a reply to message #29135] Thu, 11 September 2003 08:00 Go to previous message
Eclipse UserFriend
Originally posted by: ihc.sas-glas.mottmac.com

Thanks, I will read the Errata.

I will have to investigate overriding
XSDEcoreBuilder.getEClassifier(XSDTypeDefinition) because I don't want to
lose the type information.

What's the rationale behind the change? I can understand that mapping to
string is a Java-friendly thing to do - since for example the other kinds
of "integer" may not fit into a Java int. But I'd have thought that the
original implementation is the ideal compromise - a string but yet
preserving the original type info in the "name" for people who want it.

Ian

Dave Steinberg wrote:

> Ian Cornwell wrote:
> > For XML Schema simple types that are not included in the table on p.140
> > (or derived from these), the book says we should get an EDataType with
> > name equal to the XML Schema type, and instanceClassName of
> > java.lang.String.
> > ...
> > Which is wrong - me, the book or the code?

> Hi Ian,

> Unfortunately, the book.

> The book's companion web site (http://www.aw.com/budinsky/) includes an
> Errata ( http://wps.aw.com/aw_budinsky_eclipsemod_1/0,7999,967283-,00 .html).
> You'll notice that this problem comes up twice: on page 82 and on page 140.

> The book describes the way it used to work, and then the current, simpler
> approach was adopted later on in the publishing cycle. The text was never
> updated to reflect the change.

> Please continue refer to the Errata when things don't seem quite right, and
> do let us know if you find any other problems that we haven't caught yet, so
> that we can keep it up to date.

> Thanks,
> Dave
Re: Ecore mapping of simple types [message #29323 is a reply to message #29248] Wed, 10 September 2003 23:42 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Ian,

The rationale is a poor one and was only intended to simplify the results produced
by the 1.1.x stream. In the 2.0 stream the support is there in a much fuller way.
Even the baseType/itemType/memberTypes are recorded in the Ecore model for the
EDataType (as an EAnnotation) and it's possible to use an annotation
(non-schema-namespace attribute) in the .xsd (e.g.,
ecore:instanceClass="org.example.MyClass") to specify the instance class of the
EDataType that results from every XSDSimpleTypeDefinition. We'll also be
providing a package that represents all the EDataTypes that are produced from the
built-in types in the schema for schemas (and one that supports the attributes
declared in the XML namespace schema).

I'll look into how soon we can make available a preliminary version of 2.0...


Ian Cornwell wrote:

> Thanks, I will read the Errata.
>
> I will have to investigate overriding
> XSDEcoreBuilder.getEClassifier(XSDTypeDefinition) because I don't want to
> lose the type information.
>
> What's the rationale behind the change? I can understand that mapping to
> string is a Java-friendly thing to do - since for example the other kinds
> of "integer" may not fit into a Java int. But I'd have thought that the
> original implementation is the ideal compromise - a string but yet
> preserving the original type info in the "name" for people who want it.
>
> Ian
>
> Dave Steinberg wrote:
>
> > Ian Cornwell wrote:
> > > For XML Schema simple types that are not included in the table on p.140
> > > (or derived from these), the book says we should get an EDataType with
> > > name equal to the XML Schema type, and instanceClassName of
> > > java.lang.String.
> > > ...
> > > Which is wrong - me, the book or the code?
>
> > Hi Ian,
>
> > Unfortunately, the book.
>
> > The book's companion web site (http://www.aw.com/budinsky/) includes an
> > Errata ( http://wps.aw.com/aw_budinsky_eclipsemod_1/0,7999,967283-,00 .html).
> > You'll notice that this problem comes up twice: on page 82 and on page 140.
>
> > The book describes the way it used to work, and then the current, simpler
> > approach was adopted later on in the publishing cycle. The text was never
> > updated to reflect the change.
>
> > Please continue refer to the Errata when things don't seem quite right, and
> > do let us know if you find any other problems that we haven't caught yet, so
> > that we can keep it up to date.
>
> > Thanks,
> > Dave
Re: Ecore mapping of simple types [message #577690 is a reply to message #28914] Wed, 10 September 2003 18:25 Go to previous message
David Steinberg is currently offline David SteinbergFriend
Messages: 489
Registered: July 2009
Senior Member
Ian Cornwell wrote:
> For XML Schema simple types that are not included in the table on p.140
> (or derived from these), the book says we should get an EDataType with
> name equal to the XML Schema type, and instanceClassName of
> java.lang.String.
> ...
> Which is wrong - me, the book or the code?

Hi Ian,

Unfortunately, the book.

The book's companion web site (http://www.aw.com/budinsky/) includes an
Errata ( http://wps.aw.com/aw_budinsky_eclipsemod_1/0,7999,967283-,00 .html).
You'll notice that this problem comes up twice: on page 82 and on page 140.

The book describes the way it used to work, and then the current, simpler
approach was adopted later on in the publishing cycle. The text was never
updated to reflect the change.

Please continue refer to the Errata when things don't seem quite right, and
do let us know if you find any other problems that we haven't caught yet, so
that we can keep it up to date.

Thanks,
Dave
Re: Ecore mapping of simple types [message #577832 is a reply to message #29135] Thu, 11 September 2003 08:00 Go to previous message
Eclipse UserFriend
Originally posted by: ihc.sas-glas.mottmac.com

Thanks, I will read the Errata.

I will have to investigate overriding
XSDEcoreBuilder.getEClassifier(XSDTypeDefinition) because I don't want to
lose the type information.

What's the rationale behind the change? I can understand that mapping to
string is a Java-friendly thing to do - since for example the other kinds
of "integer" may not fit into a Java int. But I'd have thought that the
original implementation is the ideal compromise - a string but yet
preserving the original type info in the "name" for people who want it.

Ian

Dave Steinberg wrote:

> Ian Cornwell wrote:
> > For XML Schema simple types that are not included in the table on p.140
> > (or derived from these), the book says we should get an EDataType with
> > name equal to the XML Schema type, and instanceClassName of
> > java.lang.String.
> > ...
> > Which is wrong - me, the book or the code?

> Hi Ian,

> Unfortunately, the book.

> The book's companion web site (http://www.aw.com/budinsky/) includes an
> Errata ( http://wps.aw.com/aw_budinsky_eclipsemod_1/0,7999,967283-,00 .html).
> You'll notice that this problem comes up twice: on page 82 and on page 140.

> The book describes the way it used to work, and then the current, simpler
> approach was adopted later on in the publishing cycle. The text was never
> updated to reflect the change.

> Please continue refer to the Errata when things don't seem quite right, and
> do let us know if you find any other problems that we haven't caught yet, so
> that we can keep it up to date.

> Thanks,
> Dave
Re: Ecore mapping of simple types [message #577928 is a reply to message #29248] Wed, 10 September 2003 23:42 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26285
Registered: July 2009
Senior Member
Ian,

The rationale is a poor one and was only intended to simplify the results produced
by the 1.1.x stream. In the 2.0 stream the support is there in a much fuller way.
Even the baseType/itemType/memberTypes are recorded in the Ecore model for the
EDataType (as an EAnnotation) and it's possible to use an annotation
(non-schema-namespace attribute) in the .xsd (e.g.,
ecore:instanceClass="org.example.MyClass") to specify the instance class of the
EDataType that results from every XSDSimpleTypeDefinition. We'll also be
providing a package that represents all the EDataTypes that are produced from the
built-in types in the schema for schemas (and one that supports the attributes
declared in the XML namespace schema).

I'll look into how soon we can make available a preliminary version of 2.0...


Ian Cornwell wrote:

> Thanks, I will read the Errata.
>
> I will have to investigate overriding
> XSDEcoreBuilder.getEClassifier(XSDTypeDefinition) because I don't want to
> lose the type information.
>
> What's the rationale behind the change? I can understand that mapping to
> string is a Java-friendly thing to do - since for example the other kinds
> of "integer" may not fit into a Java int. But I'd have thought that the
> original implementation is the ideal compromise - a string but yet
> preserving the original type info in the "name" for people who want it.
>
> Ian
>
> Dave Steinberg wrote:
>
> > Ian Cornwell wrote:
> > > For XML Schema simple types that are not included in the table on p.140
> > > (or derived from these), the book says we should get an EDataType with
> > > name equal to the XML Schema type, and instanceClassName of
> > > java.lang.String.
> > > ...
> > > Which is wrong - me, the book or the code?
>
> > Hi Ian,
>
> > Unfortunately, the book.
>
> > The book's companion web site (http://www.aw.com/budinsky/) includes an
> > Errata ( http://wps.aw.com/aw_budinsky_eclipsemod_1/0,7999,967283-,00 .html).
> > You'll notice that this problem comes up twice: on page 82 and on page 140.
>
> > The book describes the way it used to work, and then the current, simpler
> > approach was adopted later on in the publishing cycle. The text was never
> > updated to reflect the change.
>
> > Please continue refer to the Errata when things don't seem quite right, and
> > do let us know if you find any other problems that we haven't caught yet, so
> > that we can keep it up to date.
>
> > Thanks,
> > Dave
Previous Topic:Ecore mapping discussion
Next Topic:unexpected differences with/without target namespace
Goto Forum:
  


Current Time: Sat Dec 20 13:42:13 GMT 2014

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

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