|Re: unsettable incorrect after XSD to Ecore transformation [message #1016450 is a reply to message #1016435]
||Wed, 06 March 2013 13:40
| Ed Merks
Registered: July 2009
Apparently the "needs review" comment applies. The cases for which
XSDEcoreBuilder maps an element or attribute to an unsettable feature
include single-valued features for nillable elements, single-valued
features of primitive type, single-valued non-primitive features with a
default. In each case it's driven by the need to reproduce the original
serialization, i.e., when there can be an <x xis:nil="true"/> we need to
distinguish defaulting to null and being set to null, for primitives
which always have an intrinsic default we need to distinguish, for
example an int have the value 0 because that's just the Java default,
and it having the value 0 because there was a 0 in the serialization,
and for non-primitives the same concern, i.e., the value being the
default because that's what the model populates it with verses a value
that happens to be the same as the default being present in the
serialization. If the builder isn't producing an unsettable feature,
then you don't need one. So if you want one nevertheless, you need an
ecore:unsettable annotation. Using that to turn off a feature that's
unsettable that you don't want to be unsettable will result in xsi:nil
being removed and explicit values that happen to be the same as the
intrinsic or specific default also being removed.
On 06/03/2013 2:02 PM, Lars Briem wrote:
> Corresponding to http://wiki.eclipse.org/Authoring_XML_Schemas_for_use_with_EMF the transformation process from XSD to EMF should set the attribute "unsettable" to true if a feature has a lower bound of 0 and an upper bound of 1.
>> Overrides unsettable, default value is true if lower bound is 0, OR upper bound is 1 (review needed)
> But this will not happen. Do I have to activate this functionality?
> I attached a minimal project to show the problem.
> Thanks in advance
Powered by FUDForum
. Page generated in 1.98589 seconds