Home » Archived » XML Schema Definition (XSD) » Ecore mapping of simple types
| Ecore mapping of simple types [message #28914] |
Wed, 10 September 2003 15:32  |
Eclipse User |
|
|
|
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  |
 David Steinberg
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 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 |
David Steinberg
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 |
| Eclipse User |
|
|
|
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 |
Ed Merks
Messages: 33140
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 23 13:19:18 GMT 2024
Powered by FUDForum. Page generated in 0.03589 seconds |
] 
Search
Help
Register
Login
Home
