I'd be interested in rationale and future plans in two areas where the xsd
ecore mapping loses information present in the XML Schema

1) mixed content (mixed = true)
Although I dislike the idea of mixed content, I don't have control over
the schemas that we will encounter. I sympathise with the the XSD approach
of simply having Object "contents". However, this mapping is not very
descriptive of the original XML Schema. Given that XSD 2.0 will have wider
schema-ecore mapping support I wonder if this implementation will
remain...?

2) Enumerations
Only XML Schema enumerations based on NCName become ecore enumerations.
For enumerations based on xsd:string, the XML Schema enumeration info
appears to be lost in the ecore mapping. What's the rationale here - is it
because only NCName is guaranteed to be implementable as an enum in Java?
And as above, does the expansion of ecore mapping in XSD 2.0 mean that a
change in the mapping rules is possible here?

In 2.0 there will be support for mixed that's much nicer. All the normal
features that you expect would still be generated, but their "backing store"
will delegate onto a single "mixed" feature that will consist of feature-value
pairs and this mixed feature will also be able to capture the mixed text
itself.

JAX generated enums only for NCName restrictions. In 2.0 we will generalize
this to produce an EEnum whether all the enumeration values are valid Java
identifiers.

Ian Cornwell wrote:

> I'd be interested in rationale and future plans in two areas where the xsd
> ecore mapping loses information present in the XML Schema
>
> 1) mixed content (mixed = true)
> Although I dislike the idea of mixed content, I don't have control over
> the schemas that we will encounter. I sympathise with the the XSD approach
> of simply having Object "contents". However, this mapping is not very
> descriptive of the original XML Schema. Given that XSD 2.0 will have wider
> schema-ecore mapping support I wonder if this implementation will
> remain...?
>
> 2) Enumerations
> Only XML Schema enumerations based on NCName become ecore enumerations.
> For enumerations based on xsd:string, the XML Schema enumeration info
> appears to be lost in the ecore mapping. What's the rationale here - is it
> because only NCName is guaranteed to be implementable as an enum in Java?
> And as above, does the expansion of ecore mapping in XSD 2.0 mean that a
> change in the mapping rules is possible here?
>
> Ian

In 2.0 there will be support for mixed that's much nicer. All the normal
features that you expect would still be generated, but their "backing store"
will delegate onto a single "mixed" feature that will consist of feature-value
pairs and this mixed feature will also be able to capture the mixed text
itself.

JAX generated enums only for NCName restrictions. In 2.0 we will generalize
this to produce an EEnum whether all the enumeration values are valid Java
identifiers.

Ian Cornwell wrote:

> I'd be interested in rationale and future plans in two areas where the xsd
> ecore mapping loses information present in the XML Schema
>
> 1) mixed content (mixed = true)
> Although I dislike the idea of mixed content, I don't have control over
> the schemas that we will encounter. I sympathise with the the XSD approach
> of simply having Object "contents". However, this mapping is not very
> descriptive of the original XML Schema. Given that XSD 2.0 will have wider
> schema-ecore mapping support I wonder if this implementation will
> remain...?
>
> 2) Enumerations
> Only XML Schema enumerations based on NCName become ecore enumerations.
> For enumerations based on xsd:string, the XML Schema enumeration info
> appears to be lost in the ecore mapping. What's the rationale here - is it
> because only NCName is guaranteed to be implementable as an enum in Java?
> And as above, does the expansion of ecore mapping in XSD 2.0 mean that a
> change in the mapping rules is possible here?
>
> Ian