Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Validation fails on required EAttribute (EEnum) with default literal value.
Validation fails on required EAttribute (EEnum) with default literal value. [message #468280] Tue, 04 August 2009 20:07 Go to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
I have a situation where I would like to validate an EObject that has a
default literal value for a required attribute (that is typed to an
enumeration). Is there a way for me to get validation to succeed without
having to explicitly set the value in code?
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #468338 is a reply to message #468280] Wed, 05 August 2009 07:41 Go to previous messageGo to next message
Boris Gruschko is currently offline Boris GruschkoFriend
Messages: 14
Registered: July 2009
Junior Member
Hi John,

you can set the default value in your meta-model via "Default Valu Literal"
attribute. This works for Enumeration typed attributes too.

Hope that helps and Cheers,
Boris

"John T.E. Timm" <johntimm@us.ibm.com> wrote in message
news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>I have a situation where I would like to validate an EObject that has a
>default literal value for a required attribute (that is typed to an
>enumeration). Is there a way for me to get validation to succeed without
>having to explicitly set the value in code?
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #468342 is a reply to message #468338] Wed, 05 August 2009 07:54 Go to previous messageGo to next message
Boris Gruschko is currently offline Boris GruschkoFriend
Messages: 14
Registered: July 2009
Junior Member
I just parsed your message header again. Apparently you set the deafult
literal already.

Do you set the "Default Value Literal" to the value of "Value" attribute of
the desired Enum Literal ?

I justed tested it and it validates without errors.

"Boris Gruschko" <boris.gruschko@sap.com> wrote in message
news:h5bd3e$8dq$1@build.eclipse.org...
> Hi John,
>
> you can set the default value in your meta-model via "Default Valu
> Literal" attribute. This works for Enumeration typed attributes too.
>
> Hope that helps and Cheers,
> Boris
>
> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>I have a situation where I would like to validate an EObject that has a
>>default literal value for a required attribute (that is typed to an
>>enumeration). Is there a way for me to get validation to succeed without
>>having to explicitly set the value in code?
>>
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #468500 is a reply to message #468342] Wed, 05 August 2009 16:45 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
Serialization looks at two things:

1. Whether or not the attribute is set
2. Whether or not the attribute has a default literal value (and
keepDefaults == true which is set in the resource using the
KEEP_DEFAULT_CONTENT option)

Validation seems to only look at:

1. Whether an attribute is required (lower bound > 0)
2. Whether or not an attribute is set

This being the case, if the attribute has lower bound > 0 but is not "set"
then it will always fail validation. Default literal value doesn't seem to
come into the picture. I ended up working around this by inspecting the
content tree and looking for attributes that are unset, have a default
value, and a lower bound > 0 and then setting the attribute explicitly
(eIsSet == true) in code. Here is a snippet:

if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0 &&
attribute.getDefaultValueLiteral() != null) {
if (attribute.isMany()) {
List<Object> list = (List<Object>) eObject.eGet(attribute);
list.add(attribute.getDefaultValue());
} else {
eObject.eSet(attribute, attribute.getDefaultValue());
}
}

This solution seems to be a bit of a hack, however, so if anyone knows of
a better solution please let me know.

Thanks,

JT

Boris Gruschko wrote:

> I just parsed your message header again. Apparently you set the deafult
> literal already.

> Do you set the "Default Value Literal" to the value of "Value" attribute of
> the desired Enum Literal ?

> I justed tested it and it validates without errors.

> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
> news:h5bd3e$8dq$1@build.eclipse.org...
>> Hi John,
>>
>> you can set the default value in your meta-model via "Default Valu
>> Literal" attribute. This works for Enumeration typed attributes too.
>>
>> Hope that helps and Cheers,
>> Boris
>>
>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>I have a situation where I would like to validate an EObject that has a
>>>default literal value for a required attribute (that is typed to an
>>>enumeration). Is there a way for me to get validation to succeed without
>>>having to explicitly set the value in code?
>>>
>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #468502 is a reply to message #468500] Wed, 05 August 2009 17:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
John,

Comments below.

John T.E. Timm wrote:
> Serialization looks at two things:
>
> 1. Whether or not the attribute is set
> 2. Whether or not the attribute has a default literal value (and
> keepDefaults == true which is set in the resource using the
> KEEP_DEFAULT_CONTENT option)
>
> Validation seems to only look at:
Validation works on in memory instances and cares not at all about XML
serialization or any other serialization mechanism...
>
> 1. Whether an attribute is required (lower bound > 0)
> 2. Whether or not an attribute is set
>
> This being the case, if the attribute has lower bound > 0 but is not
> "set" then it will always fail validation. Default literal value
> doesn't seem to come into the picture. I ended up working around this
> by inspecting the content tree and looking for attributes that are
> unset, have a default value, and a lower bound > 0 and then setting
> the attribute explicitly (eIsSet == true) in code. Here is a snippet:
>
> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0 &&
> attribute.getDefaultValueLiteral() != null) {
> if (attribute.isMany()) {
> List<Object> list = (List<Object>) eObject.eGet(attribute);
> list.add(attribute.getDefaultValue());
> } else {
> eObject.eSet(attribute, attribute.getDefaultValue());
> }
> }
>
> This solution seems to be a bit of a hack, however, so if anyone knows
> of a better solution please let me know.
Here's the actual logic:

{
if (eStructuralFeature.isUnsettable() ?
!eObject.eIsSet(eStructuralFeature) : eObject.eGet(eStructuralFeature,
false) == null)
{

So if a feature is unsettable, it definitely must be set, otherwise,
it's sufficient that a non-null value is by the getter (which might be
either the set value, or the default value). You've said nothing about
unsettable features so far...
>
> Thanks,
>
> JT
>
> Boris Gruschko wrote:
>
>> I just parsed your message header again. Apparently you set the
>> deafult literal already.
>
>> Do you set the "Default Value Literal" to the value of "Value"
>> attribute of the desired Enum Literal ?
>
>> I justed tested it and it validates without errors.
>
>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>> news:h5bd3e$8dq$1@build.eclipse.org...
>>> Hi John,
>>>
>>> you can set the default value in your meta-model via "Default Valu
>>> Literal" attribute. This works for Enumeration typed attributes too.
>>>
>>> Hope that helps and Cheers,
>>> Boris
>>>
>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>> I have a situation where I would like to validate an EObject that
>>>> has a default literal value for a required attribute (that is typed
>>>> to an enumeration). Is there a way for me to get validation to
>>>> succeed without having to explicitly set the value in code?
>>>>
>>>
>
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #469030 is a reply to message #468502] Wed, 05 August 2009 17:26 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
I made these feature unsettable because of serialization and circumstances
where both conditions fail (is set or (keep defaults and has default
literal)) even if i explicitly set value in code. This happens when
feature isUnsettable = false, does not have default literal and value is
set in code to the first member of the enum. This prompted me to make all
enum features isUnsettable = true. But the consequence of that, seems to
be validation.

Maybe I can't have it both ways where both serialization and validation
work in all cases...

JT

Ed Merks wrote:

> John,

> Comments below.

> John T.E. Timm wrote:
>> Serialization looks at two things:
>>
>> 1. Whether or not the attribute is set
>> 2. Whether or not the attribute has a default literal value (and
>> keepDefaults == true which is set in the resource using the
>> KEEP_DEFAULT_CONTENT option)
>>
>> Validation seems to only look at:
> Validation works on in memory instances and cares not at all about XML
> serialization or any other serialization mechanism...
>>
>> 1. Whether an attribute is required (lower bound > 0)
>> 2. Whether or not an attribute is set
>>
>> This being the case, if the attribute has lower bound > 0 but is not
>> "set" then it will always fail validation. Default literal value
>> doesn't seem to come into the picture. I ended up working around this
>> by inspecting the content tree and looking for attributes that are
>> unset, have a default value, and a lower bound > 0 and then setting
>> the attribute explicitly (eIsSet == true) in code. Here is a snippet:
>>
>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0 &&
>> attribute.getDefaultValueLiteral() != null) {
>> if (attribute.isMany()) {
>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>> list.add(attribute.getDefaultValue());
>> } else {
>> eObject.eSet(attribute, attribute.getDefaultValue());
>> }
>> }
>>
>> This solution seems to be a bit of a hack, however, so if anyone knows
>> of a better solution please let me know.
> Here's the actual logic:

> {
> if (eStructuralFeature.isUnsettable() ?
> !eObject.eIsSet(eStructuralFeature) : eObject.eGet(eStructuralFeature,
> false) == null)
> {

> So if a feature is unsettable, it definitely must be set, otherwise,
> it's sufficient that a non-null value is by the getter (which might be
> either the set value, or the default value). You've said nothing about
> unsettable features so far...
>>
>> Thanks,
>>
>> JT
>>
>> Boris Gruschko wrote:
>>
>>> I just parsed your message header again. Apparently you set the
>>> deafult literal already.
>>
>>> Do you set the "Default Value Literal" to the value of "Value"
>>> attribute of the desired Enum Literal ?
>>
>>> I justed tested it and it validates without errors.
>>
>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>> Hi John,
>>>>
>>>> you can set the default value in your meta-model via "Default Valu
>>>> Literal" attribute. This works for Enumeration typed attributes too.
>>>>
>>>> Hope that helps and Cheers,
>>>> Boris
>>>>
>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>> I have a situation where I would like to validate an EObject that
>>>>> has a default literal value for a required attribute (that is typed
>>>>> to an enumeration). Is there a way for me to get validation to
>>>>> succeed without having to explicitly set the value in code?
>>>>>
>>>>
>>
>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #469240 is a reply to message #469030] Wed, 05 August 2009 17:35 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
I guess one possibility is to only make features unsettable if they do not
have a default literal value. but then I am handling EEnums two different
ways in my model and maintenance becomes an issue. There are a few hundred
of these type of attributes.

JT

John T.E. Timm wrote:

> I made these feature unsettable because of serialization and circumstances
> where both conditions fail (is set or (keep defaults and has default
> literal)) even if i explicitly set value in code. This happens when
> feature isUnsettable = false, does not have default literal and value is
> set in code to the first member of the enum. This prompted me to make all
> enum features isUnsettable = true. But the consequence of that, seems to
> be validation.

> Maybe I can't have it both ways where both serialization and validation
> work in all cases...

> JT

> Ed Merks wrote:

>> John,

>> Comments below.

>> John T.E. Timm wrote:
>>> Serialization looks at two things:
>>>
>>> 1. Whether or not the attribute is set
>>> 2. Whether or not the attribute has a default literal value (and
>>> keepDefaults == true which is set in the resource using the
>>> KEEP_DEFAULT_CONTENT option)
>>>
>>> Validation seems to only look at:
>> Validation works on in memory instances and cares not at all about XML
>> serialization or any other serialization mechanism...
>>>
>>> 1. Whether an attribute is required (lower bound > 0)
>>> 2. Whether or not an attribute is set
>>>
>>> This being the case, if the attribute has lower bound > 0 but is not
>>> "set" then it will always fail validation. Default literal value
>>> doesn't seem to come into the picture. I ended up working around this
>>> by inspecting the content tree and looking for attributes that are
>>> unset, have a default value, and a lower bound > 0 and then setting
>>> the attribute explicitly (eIsSet == true) in code. Here is a snippet:
>>>
>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0 &&
>>> attribute.getDefaultValueLiteral() != null) {
>>> if (attribute.isMany()) {
>>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>>> list.add(attribute.getDefaultValue());
>>> } else {
>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>> }
>>> }
>>>
>>> This solution seems to be a bit of a hack, however, so if anyone knows
>>> of a better solution please let me know.
>> Here's the actual logic:

>> {
>> if (eStructuralFeature.isUnsettable() ?
>> !eObject.eIsSet(eStructuralFeature) : eObject.eGet(eStructuralFeature,
>> false) == null)
>> {

>> So if a feature is unsettable, it definitely must be set, otherwise,
>> it's sufficient that a non-null value is by the getter (which might be
>> either the set value, or the default value). You've said nothing about
>> unsettable features so far...
>>>
>>> Thanks,
>>>
>>> JT
>>>
>>> Boris Gruschko wrote:
>>>
>>>> I just parsed your message header again. Apparently you set the
>>>> deafult literal already.
>>>
>>>> Do you set the "Default Value Literal" to the value of "Value"
>>>> attribute of the desired Enum Literal ?
>>>
>>>> I justed tested it and it validates without errors.
>>>
>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>> Hi John,
>>>>>
>>>>> you can set the default value in your meta-model via "Default Valu
>>>>> Literal" attribute. This works for Enumeration typed attributes too.
>>>>>
>>>>> Hope that helps and Cheers,
>>>>> Boris
>>>>>
>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>> I have a situation where I would like to validate an EObject that
>>>>>> has a default literal value for a required attribute (that is typed
>>>>>> to an enumeration). Is there a way for me to get validation to
>>>>>> succeed without having to explicitly set the value in code?
>>>>>>
>>>>>
>>>
>>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #469771 is a reply to message #469240] Wed, 05 August 2009 17:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
John,

I suppose that setting an explicit default in each feature and keeping
the default during serialization would solve all your problems...


John T.E. Timm wrote:
> I guess one possibility is to only make features unsettable if they do
> not have a default literal value. but then I am handling EEnums two
> different ways in my model and maintenance becomes an issue. There are
> a few hundred of these type of attributes.
>
> JT
>
> John T.E. Timm wrote:
>
>> I made these feature unsettable because of serialization and
>> circumstances where both conditions fail (is set or (keep defaults
>> and has default literal)) even if i explicitly set value in code.
>> This happens when feature isUnsettable = false, does not have default
>> literal and value is set in code to the first member of the enum.
>> This prompted me to make all enum features isUnsettable = true. But
>> the consequence of that, seems to be validation.
>
>> Maybe I can't have it both ways where both serialization and
>> validation work in all cases...
>
>> JT
>
>> Ed Merks wrote:
>
>>> John,
>
>>> Comments below.
>
>>> John T.E. Timm wrote:
>>>> Serialization looks at two things:
>>>>
>>>> 1. Whether or not the attribute is set
>>>> 2. Whether or not the attribute has a default literal value (and
>>>> keepDefaults == true which is set in the resource using the
>>>> KEEP_DEFAULT_CONTENT option)
>>>>
>>>> Validation seems to only look at:
>>> Validation works on in memory instances and cares not at all about
>>> XML serialization or any other serialization mechanism...
>>>>
>>>> 1. Whether an attribute is required (lower bound > 0)
>>>> 2. Whether or not an attribute is set
>>>>
>>>> This being the case, if the attribute has lower bound > 0 but is
>>>> not "set" then it will always fail validation. Default literal
>>>> value doesn't seem to come into the picture. I ended up working
>>>> around this by inspecting the content tree and looking for
>>>> attributes that are unset, have a default value, and a lower bound
>>>> > 0 and then setting the attribute explicitly (eIsSet == true) in
>>>> code. Here is a snippet:
>>>>
>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0 &&
>>>> attribute.getDefaultValueLiteral() != null) {
>>>> if (attribute.isMany()) {
>>>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>>>> list.add(attribute.getDefaultValue());
>>>> } else {
>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>> }
>>>> }
>>>>
>>>> This solution seems to be a bit of a hack, however, so if anyone
>>>> knows of a better solution please let me know.
>>> Here's the actual logic:
>
>>> {
>>> if (eStructuralFeature.isUnsettable() ?
>>> !eObject.eIsSet(eStructuralFeature) :
>>> eObject.eGet(eStructuralFeature, false) == null)
>>> {
>
>>> So if a feature is unsettable, it definitely must be set, otherwise,
>>> it's sufficient that a non-null value is by the getter (which might
>>> be either the set value, or the default value). You've said nothing
>>> about unsettable features so far...
>>>>
>>>> Thanks,
>>>>
>>>> JT
>>>>
>>>> Boris Gruschko wrote:
>>>>
>>>>> I just parsed your message header again. Apparently you set the
>>>>> deafult literal already.
>>>>
>>>>> Do you set the "Default Value Literal" to the value of "Value"
>>>>> attribute of the desired Enum Literal ?
>>>>
>>>>> I justed tested it and it validates without errors.
>>>>
>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>> Hi John,
>>>>>>
>>>>>> you can set the default value in your meta-model via "Default
>>>>>> Valu Literal" attribute. This works for Enumeration typed
>>>>>> attributes too.
>>>>>>
>>>>>> Hope that helps and Cheers,
>>>>>> Boris
>>>>>>
>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>> I have a situation where I would like to validate an EObject
>>>>>>> that has a default literal value for a required attribute (that
>>>>>>> is typed to an enumeration). Is there a way for me to get
>>>>>>> validation to succeed without having to explicitly set the value
>>>>>>> in code?
>>>>>>>
>>>>>>
>>>>
>>>>
>
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #470173 is a reply to message #469771] Wed, 05 August 2009 17:49 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
Ed,

Thanks for the suggestion, but unfortunately, I have to live with the
scenario that some attributes have default values and other do not as this
is an implementation of a standard and I cannot make up or serialize
default values if the standard does not explicitly allow me to do so for a
given attribute.

Thanks,

JT

Ed Merks wrote:

> John,

> I suppose that setting an explicit default in each feature and keeping
> the default during serialization would solve all your problems...


> John T.E. Timm wrote:
>> I guess one possibility is to only make features unsettable if they do
>> not have a default literal value. but then I am handling EEnums two
>> different ways in my model and maintenance becomes an issue. There are
>> a few hundred of these type of attributes.
>>
>> JT
>>
>> John T.E. Timm wrote:
>>
>>> I made these feature unsettable because of serialization and
>>> circumstances where both conditions fail (is set or (keep defaults
>>> and has default literal)) even if i explicitly set value in code.
>>> This happens when feature isUnsettable = false, does not have default
>>> literal and value is set in code to the first member of the enum.
>>> This prompted me to make all enum features isUnsettable = true. But
>>> the consequence of that, seems to be validation.
>>
>>> Maybe I can't have it both ways where both serialization and
>>> validation work in all cases...
>>
>>> JT
>>
>>> Ed Merks wrote:
>>
>>>> John,
>>
>>>> Comments below.
>>
>>>> John T.E. Timm wrote:
>>>>> Serialization looks at two things:
>>>>>
>>>>> 1. Whether or not the attribute is set
>>>>> 2. Whether or not the attribute has a default literal value (and
>>>>> keepDefaults == true which is set in the resource using the
>>>>> KEEP_DEFAULT_CONTENT option)
>>>>>
>>>>> Validation seems to only look at:
>>>> Validation works on in memory instances and cares not at all about
>>>> XML serialization or any other serialization mechanism...
>>>>>
>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>> 2. Whether or not an attribute is set
>>>>>
>>>>> This being the case, if the attribute has lower bound > 0 but is
>>>>> not "set" then it will always fail validation. Default literal
>>>>> value doesn't seem to come into the picture. I ended up working
>>>>> around this by inspecting the content tree and looking for
>>>>> attributes that are unset, have a default value, and a lower bound
>>>>> > 0 and then setting the attribute explicitly (eIsSet == true) in
>>>>> code. Here is a snippet:
>>>>>
>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0 &&
>>>>> attribute.getDefaultValueLiteral() != null) {
>>>>> if (attribute.isMany()) {
>>>>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>>>>> list.add(attribute.getDefaultValue());
>>>>> } else {
>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>> }
>>>>> }
>>>>>
>>>>> This solution seems to be a bit of a hack, however, so if anyone
>>>>> knows of a better solution please let me know.
>>>> Here's the actual logic:
>>
>>>> {
>>>> if (eStructuralFeature.isUnsettable() ?
>>>> !eObject.eIsSet(eStructuralFeature) :
>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>> {
>>
>>>> So if a feature is unsettable, it definitely must be set, otherwise,
>>>> it's sufficient that a non-null value is by the getter (which might
>>>> be either the set value, or the default value). You've said nothing
>>>> about unsettable features so far...
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JT
>>>>>
>>>>> Boris Gruschko wrote:
>>>>>
>>>>>> I just parsed your message header again. Apparently you set the
>>>>>> deafult literal already.
>>>>>
>>>>>> Do you set the "Default Value Literal" to the value of "Value"
>>>>>> attribute of the desired Enum Literal ?
>>>>>
>>>>>> I justed tested it and it validates without errors.
>>>>>
>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>> Hi John,
>>>>>>>
>>>>>>> you can set the default value in your meta-model via "Default
>>>>>>> Valu Literal" attribute. This works for Enumeration typed
>>>>>>> attributes too.
>>>>>>>
>>>>>>> Hope that helps and Cheers,
>>>>>>> Boris
>>>>>>>
>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>> I have a situation where I would like to validate an EObject
>>>>>>>> that has a default literal value for a required attribute (that
>>>>>>>> is typed to an enumeration). Is there a way for me to get
>>>>>>>> validation to succeed without having to explicitly set the value
>>>>>>>> in code?
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>
>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #471405 is a reply to message #470173] Wed, 05 August 2009 18:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
John,

Unfortunately the information you supply comes in tiny snippets that
make it hard for me to make sense of the whole picture. Generally if an
attribute is required in XML, you should expect to be required to
set/choose that value explicitly; certainly when using DOM that would be
required... And in XML Schema, only optional attributes can have a
default because of course, if the attribute were required to be present
in the XML instance then any default in the model would never be
applicable to any instance...


John T.E. Timm wrote:
> Ed,
>
> Thanks for the suggestion, but unfortunately, I have to live with the
> scenario that some attributes have default values and other do not as
> this is an implementation of a standard and I cannot make up or
> serialize default values if the standard does not explicitly allow me
> to do so for a given attribute.
>
> Thanks,
>
> JT
>
> Ed Merks wrote:
>
>> John,
>
>> I suppose that setting an explicit default in each feature and
>> keeping the default during serialization would solve all your
>> problems...
>
>
>> John T.E. Timm wrote:
>>> I guess one possibility is to only make features unsettable if they
>>> do not have a default literal value. but then I am handling EEnums
>>> two different ways in my model and maintenance becomes an issue.
>>> There are a few hundred of these type of attributes.
>>>
>>> JT
>>>
>>> John T.E. Timm wrote:
>>>
>>>> I made these feature unsettable because of serialization and
>>>> circumstances where both conditions fail (is set or (keep defaults
>>>> and has default literal)) even if i explicitly set value in code.
>>>> This happens when feature isUnsettable = false, does not have
>>>> default literal and value is set in code to the first member of the
>>>> enum. This prompted me to make all enum features isUnsettable =
>>>> true. But the consequence of that, seems to be validation.
>>>
>>>> Maybe I can't have it both ways where both serialization and
>>>> validation work in all cases...
>>>
>>>> JT
>>>
>>>> Ed Merks wrote:
>>>
>>>>> John,
>>>
>>>>> Comments below.
>>>
>>>>> John T.E. Timm wrote:
>>>>>> Serialization looks at two things:
>>>>>>
>>>>>> 1. Whether or not the attribute is set
>>>>>> 2. Whether or not the attribute has a default literal value (and
>>>>>> keepDefaults == true which is set in the resource using the
>>>>>> KEEP_DEFAULT_CONTENT option)
>>>>>>
>>>>>> Validation seems to only look at:
>>>>> Validation works on in memory instances and cares not at all about
>>>>> XML serialization or any other serialization mechanism...
>>>>>>
>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>> 2. Whether or not an attribute is set
>>>>>>
>>>>>> This being the case, if the attribute has lower bound > 0 but is
>>>>>> not "set" then it will always fail validation. Default literal
>>>>>> value doesn't seem to come into the picture. I ended up working
>>>>>> around this by inspecting the content tree and looking for
>>>>>> attributes that are unset, have a default value, and a lower
>>>>>> bound > 0 and then setting the attribute explicitly (eIsSet ==
>>>>>> true) in code. Here is a snippet:
>>>>>>
>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0
>>>>>> && attribute.getDefaultValueLiteral() != null) {
>>>>>> if (attribute.isMany()) {
>>>>>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>>>>>> list.add(attribute.getDefaultValue());
>>>>>> } else {
>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> This solution seems to be a bit of a hack, however, so if anyone
>>>>>> knows of a better solution please let me know.
>>>>> Here's the actual logic:
>>>
>>>>> {
>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>> {
>>>
>>>>> So if a feature is unsettable, it definitely must be set,
>>>>> otherwise, it's sufficient that a non-null value is by the getter
>>>>> (which might be either the set value, or the default value).
>>>>> You've said nothing about unsettable features so far...
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> JT
>>>>>>
>>>>>> Boris Gruschko wrote:
>>>>>>
>>>>>>> I just parsed your message header again. Apparently you set the
>>>>>>> deafult literal already.
>>>>>>
>>>>>>> Do you set the "Default Value Literal" to the value of "Value"
>>>>>>> attribute of the desired Enum Literal ?
>>>>>>
>>>>>>> I justed tested it and it validates without errors.
>>>>>>
>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>> Hi John,
>>>>>>>>
>>>>>>>> you can set the default value in your meta-model via "Default
>>>>>>>> Valu Literal" attribute. This works for Enumeration typed
>>>>>>>> attributes too.
>>>>>>>>
>>>>>>>> Hope that helps and Cheers,
>>>>>>>> Boris
>>>>>>>>
>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>> I have a situation where I would like to validate an EObject
>>>>>>>>> that has a default literal value for a required attribute
>>>>>>>>> (that is typed to an enumeration). Is there a way for me to
>>>>>>>>> get validation to succeed without having to explicitly set the
>>>>>>>>> value in code?
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #472045 is a reply to message #471405] Wed, 05 August 2009 19:21 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
Ed,

Sorry for the lack of a summary or "big picture" to frame my issues. This
particular standard is "interesting" in terms of how it addresses
attributes. They have optional attributes with fixed values and required
attributes with default values (and everything in between). I will have a
couple different varieties:

required attributes without default values
required attributes with default values
optional attributes without default values
optional attributes with "fixed" values

My concern orginally came in modeling required attributes without default
values. I was setting the value explicitly in code and it wasn't getting
serialized. I found that this was because eIsSet was checking whether the
value was different from default (which happens to be first member of
enum). So if I set the value to first member of enum, I thought it was
set, when in fact it wasn't. So, I went and changed all these types of
attributes to isUnsettable = true. Voila! Problem fixed.

Now I have a scenario where the validator will not pick up an attribute
value even if eGet != null because I am using isUnsettable = true. So I
suppose this is the side-effect of the solution to my first issue. I see
two possible solutions to this second issue: 1. iterate over content tree
and explicitly set values that are unset with lower bound > 0 and default
literal (my current solution) or 2. covert some attributes back to
isUnsettable = false (i.e. if they have a default literal value). The
first solution is bit of a hack and the second solution may be error-prone
to maintain (if/when the standard changes). I would like to set the
default literal value for everything and I agree that this really would be
a pretty solid solution, but I don't think I have that option.

Thanks,

JT

Ed Merks wrote:

> John,

> Unfortunately the information you supply comes in tiny snippets that
> make it hard for me to make sense of the whole picture. Generally if an
> attribute is required in XML, you should expect to be required to
> set/choose that value explicitly; certainly when using DOM that would be
> required... And in XML Schema, only optional attributes can have a
> default because of course, if the attribute were required to be present
> in the XML instance then any default in the model would never be
> applicable to any instance...


> John T.E. Timm wrote:
>> Ed,
>>
>> Thanks for the suggestion, but unfortunately, I have to live with the
>> scenario that some attributes have default values and other do not as
>> this is an implementation of a standard and I cannot make up or
>> serialize default values if the standard does not explicitly allow me
>> to do so for a given attribute.
>>
>> Thanks,
>>
>> JT
>>
>> Ed Merks wrote:
>>
>>> John,
>>
>>> I suppose that setting an explicit default in each feature and
>>> keeping the default during serialization would solve all your
>>> problems...
>>
>>
>>> John T.E. Timm wrote:
>>>> I guess one possibility is to only make features unsettable if they
>>>> do not have a default literal value. but then I am handling EEnums
>>>> two different ways in my model and maintenance becomes an issue.
>>>> There are a few hundred of these type of attributes.
>>>>
>>>> JT
>>>>
>>>> John T.E. Timm wrote:
>>>>
>>>>> I made these feature unsettable because of serialization and
>>>>> circumstances where both conditions fail (is set or (keep defaults
>>>>> and has default literal)) even if i explicitly set value in code.
>>>>> This happens when feature isUnsettable = false, does not have
>>>>> default literal and value is set in code to the first member of the
>>>>> enum. This prompted me to make all enum features isUnsettable =
>>>>> true. But the consequence of that, seems to be validation.
>>>>
>>>>> Maybe I can't have it both ways where both serialization and
>>>>> validation work in all cases...
>>>>
>>>>> JT
>>>>
>>>>> Ed Merks wrote:
>>>>
>>>>>> John,
>>>>
>>>>>> Comments below.
>>>>
>>>>>> John T.E. Timm wrote:
>>>>>>> Serialization looks at two things:
>>>>>>>
>>>>>>> 1. Whether or not the attribute is set
>>>>>>> 2. Whether or not the attribute has a default literal value (and
>>>>>>> keepDefaults == true which is set in the resource using the
>>>>>>> KEEP_DEFAULT_CONTENT option)
>>>>>>>
>>>>>>> Validation seems to only look at:
>>>>>> Validation works on in memory instances and cares not at all about
>>>>>> XML serialization or any other serialization mechanism...
>>>>>>>
>>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>>> 2. Whether or not an attribute is set
>>>>>>>
>>>>>>> This being the case, if the attribute has lower bound > 0 but is
>>>>>>> not "set" then it will always fail validation. Default literal
>>>>>>> value doesn't seem to come into the picture. I ended up working
>>>>>>> around this by inspecting the content tree and looking for
>>>>>>> attributes that are unset, have a default value, and a lower
>>>>>>> bound > 0 and then setting the attribute explicitly (eIsSet ==
>>>>>>> true) in code. Here is a snippet:
>>>>>>>
>>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0
>>>>>>> && attribute.getDefaultValueLiteral() != null) {
>>>>>>> if (attribute.isMany()) {
>>>>>>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>>>>>>> list.add(attribute.getDefaultValue());
>>>>>>> } else {
>>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> This solution seems to be a bit of a hack, however, so if anyone
>>>>>>> knows of a better solution please let me know.
>>>>>> Here's the actual logic:
>>>>
>>>>>> {
>>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>>> {
>>>>
>>>>>> So if a feature is unsettable, it definitely must be set,
>>>>>> otherwise, it's sufficient that a non-null value is by the getter
>>>>>> (which might be either the set value, or the default value).
>>>>>> You've said nothing about unsettable features so far...
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> JT
>>>>>>>
>>>>>>> Boris Gruschko wrote:
>>>>>>>
>>>>>>>> I just parsed your message header again. Apparently you set the
>>>>>>>> deafult literal already.
>>>>>>>
>>>>>>>> Do you set the "Default Value Literal" to the value of "Value"
>>>>>>>> attribute of the desired Enum Literal ?
>>>>>>>
>>>>>>>> I justed tested it and it validates without errors.
>>>>>>>
>>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> you can set the default value in your meta-model via "Default
>>>>>>>>> Valu Literal" attribute. This works for Enumeration typed
>>>>>>>>> attributes too.
>>>>>>>>>
>>>>>>>>> Hope that helps and Cheers,
>>>>>>>>> Boris
>>>>>>>>>
>>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>>> I have a situation where I would like to validate an EObject
>>>>>>>>>> that has a default literal value for a required attribute
>>>>>>>>>> (that is typed to an enumeration). Is there a way for me to
>>>>>>>>>> get validation to succeed without having to explicitly set the
>>>>>>>>>> value in code?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #478966 is a reply to message #472045] Fri, 07 August 2009 17:07 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
One thing I forgot to mention about the use of isUnsettable = true... If I
do not use this option, then I am unable to re-serialize any attribute
that is present in the input document, does not have a default literal
value and is set to the first member of the enumeration. I think
isUnsettable = true may be critical to accurately reserializing this type
of attribute.

Thanks,

JT

John T.E. Timm wrote:

> Ed,

> Sorry for the lack of a summary or "big picture" to frame my issues. This
> particular standard is "interesting" in terms of how it addresses
> attributes. They have optional attributes with fixed values and required
> attributes with default values (and everything in between). I will have a
> couple different varieties:

> required attributes without default values
> required attributes with default values
> optional attributes without default values
> optional attributes with "fixed" values

> My concern orginally came in modeling required attributes without default
> values. I was setting the value explicitly in code and it wasn't getting
> serialized. I found that this was because eIsSet was checking whether the
> value was different from default (which happens to be first member of
> enum). So if I set the value to first member of enum, I thought it was
> set, when in fact it wasn't. So, I went and changed all these types of
> attributes to isUnsettable = true. Voila! Problem fixed.

> Now I have a scenario where the validator will not pick up an attribute
> value even if eGet != null because I am using isUnsettable = true. So I
> suppose this is the side-effect of the solution to my first issue. I see
> two possible solutions to this second issue: 1. iterate over content tree
> and explicitly set values that are unset with lower bound > 0 and default
> literal (my current solution) or 2. covert some attributes back to
> isUnsettable = false (i.e. if they have a default literal value). The
> first solution is bit of a hack and the second solution may be error-prone
> to maintain (if/when the standard changes). I would like to set the
> default literal value for everything and I agree that this really would be
> a pretty solid solution, but I don't think I have that option.

> Thanks,

> JT

> Ed Merks wrote:

>> John,

>> Unfortunately the information you supply comes in tiny snippets that
>> make it hard for me to make sense of the whole picture. Generally if an
>> attribute is required in XML, you should expect to be required to
>> set/choose that value explicitly; certainly when using DOM that would be
>> required... And in XML Schema, only optional attributes can have a
>> default because of course, if the attribute were required to be present
>> in the XML instance then any default in the model would never be
>> applicable to any instance...


>> John T.E. Timm wrote:
>>> Ed,
>>>
>>> Thanks for the suggestion, but unfortunately, I have to live with the
>>> scenario that some attributes have default values and other do not as
>>> this is an implementation of a standard and I cannot make up or
>>> serialize default values if the standard does not explicitly allow me
>>> to do so for a given attribute.
>>>
>>> Thanks,
>>>
>>> JT
>>>
>>> Ed Merks wrote:
>>>
>>>> John,
>>>
>>>> I suppose that setting an explicit default in each feature and
>>>> keeping the default during serialization would solve all your
>>>> problems...
>>>
>>>
>>>> John T.E. Timm wrote:
>>>>> I guess one possibility is to only make features unsettable if they
>>>>> do not have a default literal value. but then I am handling EEnums
>>>>> two different ways in my model and maintenance becomes an issue.
>>>>> There are a few hundred of these type of attributes.
>>>>>
>>>>> JT
>>>>>
>>>>> John T.E. Timm wrote:
>>>>>
>>>>>> I made these feature unsettable because of serialization and
>>>>>> circumstances where both conditions fail (is set or (keep defaults
>>>>>> and has default literal)) even if i explicitly set value in code.
>>>>>> This happens when feature isUnsettable = false, does not have
>>>>>> default literal and value is set in code to the first member of the
>>>>>> enum. This prompted me to make all enum features isUnsettable =
>>>>>> true. But the consequence of that, seems to be validation.
>>>>>
>>>>>> Maybe I can't have it both ways where both serialization and
>>>>>> validation work in all cases...
>>>>>
>>>>>> JT
>>>>>
>>>>>> Ed Merks wrote:
>>>>>
>>>>>>> John,
>>>>>
>>>>>>> Comments below.
>>>>>
>>>>>>> John T.E. Timm wrote:
>>>>>>>> Serialization looks at two things:
>>>>>>>>
>>>>>>>> 1. Whether or not the attribute is set
>>>>>>>> 2. Whether or not the attribute has a default literal value (and
>>>>>>>> keepDefaults == true which is set in the resource using the
>>>>>>>> KEEP_DEFAULT_CONTENT option)
>>>>>>>>
>>>>>>>> Validation seems to only look at:
>>>>>>> Validation works on in memory instances and cares not at all about
>>>>>>> XML serialization or any other serialization mechanism...
>>>>>>>>
>>>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>>>> 2. Whether or not an attribute is set
>>>>>>>>
>>>>>>>> This being the case, if the attribute has lower bound > 0 but is
>>>>>>>> not "set" then it will always fail validation. Default literal
>>>>>>>> value doesn't seem to come into the picture. I ended up working
>>>>>>>> around this by inspecting the content tree and looking for
>>>>>>>> attributes that are unset, have a default value, and a lower
>>>>>>>> bound > 0 and then setting the attribute explicitly (eIsSet ==
>>>>>>>> true) in code. Here is a snippet:
>>>>>>>>
>>>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() > 0
>>>>>>>> && attribute.getDefaultValueLiteral() != null) {
>>>>>>>> if (attribute.isMany()) {
>>>>>>>> List<Object> list = (List<Object>) eObject.eGet(attribute);
>>>>>>>> list.add(attribute.getDefaultValue());
>>>>>>>> } else {
>>>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> This solution seems to be a bit of a hack, however, so if anyone
>>>>>>>> knows of a better solution please let me know.
>>>>>>> Here's the actual logic:
>>>>>
>>>>>>> {
>>>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>>>> {
>>>>>
>>>>>>> So if a feature is unsettable, it definitely must be set,
>>>>>>> otherwise, it's sufficient that a non-null value is by the getter
>>>>>>> (which might be either the set value, or the default value).
>>>>>>> You've said nothing about unsettable features so far...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> JT
>>>>>>>>
>>>>>>>> Boris Gruschko wrote:
>>>>>>>>
>>>>>>>>> I just parsed your message header again. Apparently you set the
>>>>>>>>> deafult literal already.
>>>>>>>>
>>>>>>>>> Do you set the "Default Value Literal" to the value of "Value"
>>>>>>>>> attribute of the desired Enum Literal ?
>>>>>>>>
>>>>>>>>> I justed tested it and it validates without errors.
>>>>>>>>
>>>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>>>> Hi John,
>>>>>>>>>>
>>>>>>>>>> you can set the default value in your meta-model via "Default
>>>>>>>>>> Valu Literal" attribute. This works for Enumeration typed
>>>>>>>>>> attributes too.
>>>>>>>>>>
>>>>>>>>>> Hope that helps and Cheers,
>>>>>>>>>> Boris
>>>>>>>>>>
>>>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>>>> I have a situation where I would like to validate an EObject
>>>>>>>>>>> that has a default literal value for a required attribute
>>>>>>>>>>> (that is typed to an enumeration). Is there a way for me to
>>>>>>>>>>> get validation to succeed without having to explicitly set the
>>>>>>>>>>> value in code?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #478969 is a reply to message #478966] Fri, 07 August 2009 17:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
John,

Did you model originate as an XML Schema?

Note that what you describe is true not just of enums but also of all
primitive types...


John T.E. Timm wrote:
> One thing I forgot to mention about the use of isUnsettable = true...
> If I do not use this option, then I am unable to re-serialize any
> attribute that is present in the input document, does not have a
> default literal value and is set to the first member of the
> enumeration. I think isUnsettable = true may be critical to accurately
> reserializing this type of attribute.
>
> Thanks,
>
> JT
>
> John T.E. Timm wrote:
>
>> Ed,
>
>> Sorry for the lack of a summary or "big picture" to frame my issues.
>> This particular standard is "interesting" in terms of how it
>> addresses attributes. They have optional attributes with fixed values
>> and required attributes with default values (and everything in
>> between). I will have a couple different varieties:
>
>> required attributes without default values
>> required attributes with default values
>> optional attributes without default values
>> optional attributes with "fixed" values
>
>> My concern orginally came in modeling required attributes without
>> default values. I was setting the value explicitly in code and it
>> wasn't getting serialized. I found that this was because eIsSet was
>> checking whether the value was different from default (which happens
>> to be first member of enum). So if I set the value to first member of
>> enum, I thought it was set, when in fact it wasn't. So, I went and
>> changed all these types of attributes to isUnsettable = true. Voila!
>> Problem fixed.
>
>> Now I have a scenario where the validator will not pick up an
>> attribute value even if eGet != null because I am using isUnsettable
>> = true. So I suppose this is the side-effect of the solution to my
>> first issue. I see two possible solutions to this second issue: 1.
>> iterate over content tree and explicitly set values that are unset
>> with lower bound > 0 and default literal (my current solution) or 2.
>> covert some attributes back to isUnsettable = false (i.e. if they
>> have a default literal value). The first solution is bit of a hack
>> and the second solution may be error-prone to maintain (if/when the
>> standard changes). I would like to set the default literal value for
>> everything and I agree that this really would be a pretty solid
>> solution, but I don't think I have that option.
>
>> Thanks,
>
>> JT
>
>> Ed Merks wrote:
>
>>> John,
>
>>> Unfortunately the information you supply comes in tiny snippets that
>>> make it hard for me to make sense of the whole picture. Generally
>>> if an attribute is required in XML, you should expect to be required
>>> to set/choose that value explicitly; certainly when using DOM that
>>> would be required... And in XML Schema, only optional attributes
>>> can have a default because of course, if the attribute were required
>>> to be present in the XML instance then any default in the model
>>> would never be applicable to any instance...
>
>
>>> John T.E. Timm wrote:
>>>> Ed,
>>>>
>>>> Thanks for the suggestion, but unfortunately, I have to live with
>>>> the scenario that some attributes have default values and other do
>>>> not as this is an implementation of a standard and I cannot make up
>>>> or serialize default values if the standard does not explicitly
>>>> allow me to do so for a given attribute.
>>>>
>>>> Thanks,
>>>>
>>>> JT
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> John,
>>>>
>>>>> I suppose that setting an explicit default in each feature and
>>>>> keeping the default during serialization would solve all your
>>>>> problems...
>>>>
>>>>
>>>>> John T.E. Timm wrote:
>>>>>> I guess one possibility is to only make features unsettable if
>>>>>> they do not have a default literal value. but then I am handling
>>>>>> EEnums two different ways in my model and maintenance becomes an
>>>>>> issue. There are a few hundred of these type of attributes.
>>>>>>
>>>>>> JT
>>>>>>
>>>>>> John T.E. Timm wrote:
>>>>>>
>>>>>>> I made these feature unsettable because of serialization and
>>>>>>> circumstances where both conditions fail (is set or (keep
>>>>>>> defaults and has default literal)) even if i explicitly set
>>>>>>> value in code. This happens when feature isUnsettable = false,
>>>>>>> does not have default literal and value is set in code to the
>>>>>>> first member of the enum. This prompted me to make all enum
>>>>>>> features isUnsettable = true. But the consequence of that, seems
>>>>>>> to be validation.
>>>>>>
>>>>>>> Maybe I can't have it both ways where both serialization and
>>>>>>> validation work in all cases...
>>>>>>
>>>>>>> JT
>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>>> John,
>>>>>>
>>>>>>>> Comments below.
>>>>>>
>>>>>>>> John T.E. Timm wrote:
>>>>>>>>> Serialization looks at two things:
>>>>>>>>>
>>>>>>>>> 1. Whether or not the attribute is set
>>>>>>>>> 2. Whether or not the attribute has a default literal value
>>>>>>>>> (and keepDefaults == true which is set in the resource using
>>>>>>>>> the KEEP_DEFAULT_CONTENT option)
>>>>>>>>>
>>>>>>>>> Validation seems to only look at:
>>>>>>>> Validation works on in memory instances and cares not at all
>>>>>>>> about XML serialization or any other serialization mechanism...
>>>>>>>>>
>>>>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>>>>> 2. Whether or not an attribute is set
>>>>>>>>>
>>>>>>>>> This being the case, if the attribute has lower bound > 0 but
>>>>>>>>> is not "set" then it will always fail validation. Default
>>>>>>>>> literal value doesn't seem to come into the picture. I ended
>>>>>>>>> up working around this by inspecting the content tree and
>>>>>>>>> looking for attributes that are unset, have a default value,
>>>>>>>>> and a lower bound > 0 and then setting the attribute
>>>>>>>>> explicitly (eIsSet == true) in code. Here is a snippet:
>>>>>>>>>
>>>>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() >
>>>>>>>>> 0 && attribute.getDefaultValueLiteral() != null) {
>>>>>>>>> if (attribute.isMany()) {
>>>>>>>>> List<Object> list = (List<Object>)
>>>>>>>>> eObject.eGet(attribute);
>>>>>>>>> list.add(attribute.getDefaultValue());
>>>>>>>>> } else {
>>>>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> This solution seems to be a bit of a hack, however, so if
>>>>>>>>> anyone knows of a better solution please let me know.
>>>>>>>> Here's the actual logic:
>>>>>>
>>>>>>>> {
>>>>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>>>>> {
>>>>>>
>>>>>>>> So if a feature is unsettable, it definitely must be set,
>>>>>>>> otherwise, it's sufficient that a non-null value is by the
>>>>>>>> getter (which might be either the set value, or the default
>>>>>>>> value). You've said nothing about unsettable features so far...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> JT
>>>>>>>>>
>>>>>>>>> Boris Gruschko wrote:
>>>>>>>>>
>>>>>>>>>> I just parsed your message header again. Apparently you set
>>>>>>>>>> the deafult literal already.
>>>>>>>>>
>>>>>>>>>> Do you set the "Default Value Literal" to the value of
>>>>>>>>>> "Value" attribute of the desired Enum Literal ?
>>>>>>>>>
>>>>>>>>>> I justed tested it and it validates without errors.
>>>>>>>>>
>>>>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>>>>> Hi John,
>>>>>>>>>>>
>>>>>>>>>>> you can set the default value in your meta-model via
>>>>>>>>>>> "Default Valu Literal" attribute. This works for Enumeration
>>>>>>>>>>> typed attributes too.
>>>>>>>>>>>
>>>>>>>>>>> Hope that helps and Cheers,
>>>>>>>>>>> Boris
>>>>>>>>>>>
>>>>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>>>>> I have a situation where I would like to validate an
>>>>>>>>>>>> EObject that has a default literal value for a required
>>>>>>>>>>>> attribute (that is typed to an enumeration). Is there a way
>>>>>>>>>>>> for me to get validation to succeed without having to
>>>>>>>>>>>> explicitly set the value in code?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #478970 is a reply to message #478969] Fri, 07 August 2009 17:41 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
Ed,

The model originated from a UML model that I created manually using an XML
schema and another domain-specific modeling language as a guide. I was
unable to use the schema directly as it was too large and complex to get
any sort of meaningful code generation without significant modification
and the standards organization that it came from has said that the schema
is not normative and encourages the use of their DSL instead.

As the model does contain a few other primitive types, perhaps I should be
using the isUnsettable = true for all attributes and deal with the
consequences in validation as a separate issue.

Thanks,

JT

Ed Merks wrote:

> John,

> Did you model originate as an XML Schema?

> Note that what you describe is true not just of enums but also of all
> primitive types...


> John T.E. Timm wrote:
>> One thing I forgot to mention about the use of isUnsettable = true...
>> If I do not use this option, then I am unable to re-serialize any
>> attribute that is present in the input document, does not have a
>> default literal value and is set to the first member of the
>> enumeration. I think isUnsettable = true may be critical to accurately
>> reserializing this type of attribute.
>>
>> Thanks,
>>
>> JT
>>
>> John T.E. Timm wrote:
>>
>>> Ed,
>>
>>> Sorry for the lack of a summary or "big picture" to frame my issues.
>>> This particular standard is "interesting" in terms of how it
>>> addresses attributes. They have optional attributes with fixed values
>>> and required attributes with default values (and everything in
>>> between). I will have a couple different varieties:
>>
>>> required attributes without default values
>>> required attributes with default values
>>> optional attributes without default values
>>> optional attributes with "fixed" values
>>
>>> My concern orginally came in modeling required attributes without
>>> default values. I was setting the value explicitly in code and it
>>> wasn't getting serialized. I found that this was because eIsSet was
>>> checking whether the value was different from default (which happens
>>> to be first member of enum). So if I set the value to first member of
>>> enum, I thought it was set, when in fact it wasn't. So, I went and
>>> changed all these types of attributes to isUnsettable = true. Voila!
>>> Problem fixed.
>>
>>> Now I have a scenario where the validator will not pick up an
>>> attribute value even if eGet != null because I am using isUnsettable
>>> = true. So I suppose this is the side-effect of the solution to my
>>> first issue. I see two possible solutions to this second issue: 1.
>>> iterate over content tree and explicitly set values that are unset
>>> with lower bound > 0 and default literal (my current solution) or 2.
>>> covert some attributes back to isUnsettable = false (i.e. if they
>>> have a default literal value). The first solution is bit of a hack
>>> and the second solution may be error-prone to maintain (if/when the
>>> standard changes). I would like to set the default literal value for
>>> everything and I agree that this really would be a pretty solid
>>> solution, but I don't think I have that option.
>>
>>> Thanks,
>>
>>> JT
>>
>>> Ed Merks wrote:
>>
>>>> John,
>>
>>>> Unfortunately the information you supply comes in tiny snippets that
>>>> make it hard for me to make sense of the whole picture. Generally
>>>> if an attribute is required in XML, you should expect to be required
>>>> to set/choose that value explicitly; certainly when using DOM that
>>>> would be required... And in XML Schema, only optional attributes
>>>> can have a default because of course, if the attribute were required
>>>> to be present in the XML instance then any default in the model
>>>> would never be applicable to any instance...
>>
>>
>>>> John T.E. Timm wrote:
>>>>> Ed,
>>>>>
>>>>> Thanks for the suggestion, but unfortunately, I have to live with
>>>>> the scenario that some attributes have default values and other do
>>>>> not as this is an implementation of a standard and I cannot make up
>>>>> or serialize default values if the standard does not explicitly
>>>>> allow me to do so for a given attribute.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JT
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> John,
>>>>>
>>>>>> I suppose that setting an explicit default in each feature and
>>>>>> keeping the default during serialization would solve all your
>>>>>> problems...
>>>>>
>>>>>
>>>>>> John T.E. Timm wrote:
>>>>>>> I guess one possibility is to only make features unsettable if
>>>>>>> they do not have a default literal value. but then I am handling
>>>>>>> EEnums two different ways in my model and maintenance becomes an
>>>>>>> issue. There are a few hundred of these type of attributes.
>>>>>>>
>>>>>>> JT
>>>>>>>
>>>>>>> John T.E. Timm wrote:
>>>>>>>
>>>>>>>> I made these feature unsettable because of serialization and
>>>>>>>> circumstances where both conditions fail (is set or (keep
>>>>>>>> defaults and has default literal)) even if i explicitly set
>>>>>>>> value in code. This happens when feature isUnsettable = false,
>>>>>>>> does not have default literal and value is set in code to the
>>>>>>>> first member of the enum. This prompted me to make all enum
>>>>>>>> features isUnsettable = true. But the consequence of that, seems
>>>>>>>> to be validation.
>>>>>>>
>>>>>>>> Maybe I can't have it both ways where both serialization and
>>>>>>>> validation work in all cases...
>>>>>>>
>>>>>>>> JT
>>>>>>>
>>>>>>>> Ed Merks wrote:
>>>>>>>
>>>>>>>>> John,
>>>>>>>
>>>>>>>>> Comments below.
>>>>>>>
>>>>>>>>> John T.E. Timm wrote:
>>>>>>>>>> Serialization looks at two things:
>>>>>>>>>>
>>>>>>>>>> 1. Whether or not the attribute is set
>>>>>>>>>> 2. Whether or not the attribute has a default literal value
>>>>>>>>>> (and keepDefaults == true which is set in the resource using
>>>>>>>>>> the KEEP_DEFAULT_CONTENT option)
>>>>>>>>>>
>>>>>>>>>> Validation seems to only look at:
>>>>>>>>> Validation works on in memory instances and cares not at all
>>>>>>>>> about XML serialization or any other serialization mechanism...
>>>>>>>>>>
>>>>>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>>>>>> 2. Whether or not an attribute is set
>>>>>>>>>>
>>>>>>>>>> This being the case, if the attribute has lower bound > 0 but
>>>>>>>>>> is not "set" then it will always fail validation. Default
>>>>>>>>>> literal value doesn't seem to come into the picture. I ended
>>>>>>>>>> up working around this by inspecting the content tree and
>>>>>>>>>> looking for attributes that are unset, have a default value,
>>>>>>>>>> and a lower bound > 0 and then setting the attribute
>>>>>>>>>> explicitly (eIsSet == true) in code. Here is a snippet:
>>>>>>>>>>
>>>>>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound() >
>>>>>>>>>> 0 && attribute.getDefaultValueLiteral() != null) {
>>>>>>>>>> if (attribute.isMany()) {
>>>>>>>>>> List<Object> list = (List<Object>)
>>>>>>>>>> eObject.eGet(attribute);
>>>>>>>>>> list.add(attribute.getDefaultValue());
>>>>>>>>>> } else {
>>>>>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> This solution seems to be a bit of a hack, however, so if
>>>>>>>>>> anyone knows of a better solution please let me know.
>>>>>>>>> Here's the actual logic:
>>>>>>>
>>>>>>>>> {
>>>>>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>>>>>> {
>>>>>>>
>>>>>>>>> So if a feature is unsettable, it definitely must be set,
>>>>>>>>> otherwise, it's sufficient that a non-null value is by the
>>>>>>>>> getter (which might be either the set value, or the default
>>>>>>>>> value). You've said nothing about unsettable features so far...
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> JT
>>>>>>>>>>
>>>>>>>>>> Boris Gruschko wrote:
>>>>>>>>>>
>>>>>>>>>>> I just parsed your message header again. Apparently you set
>>>>>>>>>>> the deafult literal already.
>>>>>>>>>>
>>>>>>>>>>> Do you set the "Default Value Literal" to the value of
>>>>>>>>>>> "Value" attribute of the desired Enum Literal ?
>>>>>>>>>>
>>>>>>>>>>> I justed tested it and it validates without errors.
>>>>>>>>>>
>>>>>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>
>>>>>>>>>>>> you can set the default value in your meta-model via
>>>>>>>>>>>> "Default Valu Literal" attribute. This works for Enumeration
>>>>>>>>>>>> typed attributes too.
>>>>>>>>>>>>
>>>>>>>>>>>> Hope that helps and Cheers,
>>>>>>>>>>>> Boris
>>>>>>>>>>>>
>>>>>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>>>>>> I have a situation where I would like to validate an
>>>>>>>>>>>>> EObject that has a default literal value for a required
>>>>>>>>>>>>> attribute (that is typed to an enumeration). Is there a way
>>>>>>>>>>>>> for me to get validation to succeed without having to
>>>>>>>>>>>>> explicitly set the value in code?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>
>>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #478982 is a reply to message #478970] Fri, 07 August 2009 19:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30692
Registered: July 2009
Senior Member
John,

It's a pretty fuzzy picture. Without a normative schema, who decides
what's a valid XML serialization and what isn't?

Certainly to preserve all the XML state, the difference between an
attribute that's missing and an attribute that's present needs to be
preserved. This is like one extra state that needs to be represented in
the case of primitive values because null (no-value) is not in their
value space. Such things would generally need to be unsettable, and
enums are treated like primitives...


John T.E. Timm wrote:
> Ed,
>
> The model originated from a UML model that I created manually using an
> XML schema and another domain-specific modeling language as a guide. I
> was unable to use the schema directly as it was too large and complex
> to get any sort of meaningful code generation without significant
> modification and the standards organization that it came from has said
> that the schema is not normative and encourages the use of their DSL
> instead.
>
> As the model does contain a few other primitive types, perhaps I
> should be using the isUnsettable = true for all attributes and deal
> with the consequences in validation as a separate issue.
>
> Thanks,
>
> JT
>
> Ed Merks wrote:
>
>> John,
>
>> Did you model originate as an XML Schema?
>
>> Note that what you describe is true not just of enums but also of all
>> primitive types...
>
>
>> John T.E. Timm wrote:
>>> One thing I forgot to mention about the use of isUnsettable =
>>> true... If I do not use this option, then I am unable to
>>> re-serialize any attribute that is present in the input document,
>>> does not have a default literal value and is set to the first member
>>> of the enumeration. I think isUnsettable = true may be critical to
>>> accurately reserializing this type of attribute.
>>>
>>> Thanks,
>>>
>>> JT
>>>
>>> John T.E. Timm wrote:
>>>
>>>> Ed,
>>>
>>>> Sorry for the lack of a summary or "big picture" to frame my
>>>> issues. This particular standard is "interesting" in terms of how
>>>> it addresses attributes. They have optional attributes with fixed
>>>> values and required attributes with default values (and everything
>>>> in between). I will have a couple different varieties:
>>>
>>>> required attributes without default values
>>>> required attributes with default values
>>>> optional attributes without default values
>>>> optional attributes with "fixed" values
>>>
>>>> My concern orginally came in modeling required attributes without
>>>> default values. I was setting the value explicitly in code and it
>>>> wasn't getting serialized. I found that this was because eIsSet was
>>>> checking whether the value was different from default (which
>>>> happens to be first member of enum). So if I set the value to first
>>>> member of enum, I thought it was set, when in fact it wasn't. So, I
>>>> went and changed all these types of attributes to isUnsettable =
>>>> true. Voila! Problem fixed.
>>>
>>>> Now I have a scenario where the validator will not pick up an
>>>> attribute value even if eGet != null because I am using
>>>> isUnsettable = true. So I suppose this is the side-effect of the
>>>> solution to my first issue. I see two possible solutions to this
>>>> second issue: 1. iterate over content tree and explicitly set
>>>> values that are unset with lower bound > 0 and default literal (my
>>>> current solution) or 2. covert some attributes back to isUnsettable
>>>> = false (i.e. if they have a default literal value). The first
>>>> solution is bit of a hack and the second solution may be
>>>> error-prone to maintain (if/when the standard changes). I would
>>>> like to set the default literal value for everything and I agree
>>>> that this really would be a pretty solid solution, but I don't
>>>> think I have that option.
>>>
>>>> Thanks,
>>>
>>>> JT
>>>
>>>> Ed Merks wrote:
>>>
>>>>> John,
>>>
>>>>> Unfortunately the information you supply comes in tiny snippets
>>>>> that make it hard for me to make sense of the whole picture.
>>>>> Generally if an attribute is required in XML, you should expect to
>>>>> be required to set/choose that value explicitly; certainly when
>>>>> using DOM that would be required... And in XML Schema, only
>>>>> optional attributes can have a default because of course, if the
>>>>> attribute were required to be present in the XML instance then any
>>>>> default in the model would never be applicable to any instance...
>>>
>>>
>>>>> John T.E. Timm wrote:
>>>>>> Ed,
>>>>>>
>>>>>> Thanks for the suggestion, but unfortunately, I have to live with
>>>>>> the scenario that some attributes have default values and other
>>>>>> do not as this is an implementation of a standard and I cannot
>>>>>> make up or serialize default values if the standard does not
>>>>>> explicitly allow me to do so for a given attribute.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> JT
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>
>>>>>>> John,
>>>>>>
>>>>>>> I suppose that setting an explicit default in each feature and
>>>>>>> keeping the default during serialization would solve all your
>>>>>>> problems...
>>>>>>
>>>>>>
>>>>>>> John T.E. Timm wrote:
>>>>>>>> I guess one possibility is to only make features unsettable if
>>>>>>>> they do not have a default literal value. but then I am
>>>>>>>> handling EEnums two different ways in my model and maintenance
>>>>>>>> becomes an issue. There are a few hundred of these type of
>>>>>>>> attributes.
>>>>>>>>
>>>>>>>> JT
>>>>>>>>
>>>>>>>> John T.E. Timm wrote:
>>>>>>>>
>>>>>>>>> I made these feature unsettable because of serialization and
>>>>>>>>> circumstances where both conditions fail (is set or (keep
>>>>>>>>> defaults and has default literal)) even if i explicitly set
>>>>>>>>> value in code. This happens when feature isUnsettable = false,
>>>>>>>>> does not have default literal and value is set in code to the
>>>>>>>>> first member of the enum. This prompted me to make all enum
>>>>>>>>> features isUnsettable = true. But the consequence of that,
>>>>>>>>> seems to be validation.
>>>>>>>>
>>>>>>>>> Maybe I can't have it both ways where both serialization and
>>>>>>>>> validation work in all cases...
>>>>>>>>
>>>>>>>>> JT
>>>>>>>>
>>>>>>>>> Ed Merks wrote:
>>>>>>>>
>>>>>>>>>> John,
>>>>>>>>
>>>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>>>> John T.E. Timm wrote:
>>>>>>>>>>> Serialization looks at two things:
>>>>>>>>>>>
>>>>>>>>>>> 1. Whether or not the attribute is set
>>>>>>>>>>> 2. Whether or not the attribute has a default literal value
>>>>>>>>>>> (and keepDefaults == true which is set in the resource using
>>>>>>>>>>> the KEEP_DEFAULT_CONTENT option)
>>>>>>>>>>>
>>>>>>>>>>> Validation seems to only look at:
>>>>>>>>>> Validation works on in memory instances and cares not at all
>>>>>>>>>> about XML serialization or any other serialization mechanism...
>>>>>>>>>>>
>>>>>>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>>>>>>> 2. Whether or not an attribute is set
>>>>>>>>>>>
>>>>>>>>>>> This being the case, if the attribute has lower bound > 0
>>>>>>>>>>> but is not "set" then it will always fail validation.
>>>>>>>>>>> Default literal value doesn't seem to come into the picture.
>>>>>>>>>>> I ended up working around this by inspecting the content
>>>>>>>>>>> tree and looking for attributes that are unset, have a
>>>>>>>>>>> default value, and a lower bound > 0 and then setting the
>>>>>>>>>>> attribute explicitly (eIsSet == true) in code. Here is a
>>>>>>>>>>> snippet:
>>>>>>>>>>>
>>>>>>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound()
>>>>>>>>>>> > 0 && attribute.getDefaultValueLiteral() != null) {
>>>>>>>>>>> if (attribute.isMany()) {
>>>>>>>>>>> List<Object> list = (List<Object>)
>>>>>>>>>>> eObject.eGet(attribute);
>>>>>>>>>>> list.add(attribute.getDefaultValue());
>>>>>>>>>>> } else {
>>>>>>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> This solution seems to be a bit of a hack, however, so if
>>>>>>>>>>> anyone knows of a better solution please let me know.
>>>>>>>>>> Here's the actual logic:
>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>>>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>>>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>>>>>>> {
>>>>>>>>
>>>>>>>>>> So if a feature is unsettable, it definitely must be set,
>>>>>>>>>> otherwise, it's sufficient that a non-null value is by the
>>>>>>>>>> getter (which might be either the set value, or the default
>>>>>>>>>> value). You've said nothing about unsettable features so far...
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> JT
>>>>>>>>>>>
>>>>>>>>>>> Boris Gruschko wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I just parsed your message header again. Apparently you set
>>>>>>>>>>>> the deafult literal already.
>>>>>>>>>>>
>>>>>>>>>>>> Do you set the "Default Value Literal" to the value of
>>>>>>>>>>>> "Value" attribute of the desired Enum Literal ?
>>>>>>>>>>>
>>>>>>>>>>>> I justed tested it and it validates without errors.
>>>>>>>>>>>
>>>>>>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>>
>>>>>>>>>>>>> you can set the default value in your meta-model via
>>>>>>>>>>>>> "Default Valu Literal" attribute. This works for
>>>>>>>>>>>>> Enumeration typed attributes too.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hope that helps and Cheers,
>>>>>>>>>>>>> Boris
>>>>>>>>>>>>>
>>>>>>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>>>>>>> I have a situation where I would like to validate an
>>>>>>>>>>>>>> EObject that has a default literal value for a required
>>>>>>>>>>>>>> attribute (that is typed to an enumeration). Is there a
>>>>>>>>>>>>>> way for me to get validation to succeed without having to
>>>>>>>>>>>>>> explicitly set the value in code?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>
Re: Validation fails on required EAttribute (EEnum) with default literal value. [message #478987 is a reply to message #478982] Fri, 07 August 2009 20:34 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 160
Registered: July 2009
Senior Member
I agree. It is very fuzzy. Probably contributes to why more people have
not adopted the standard...

JT

Ed Merks wrote:

> John,

> It's a pretty fuzzy picture. Without a normative schema, who decides
> what's a valid XML serialization and what isn't?

> Certainly to preserve all the XML state, the difference between an
> attribute that's missing and an attribute that's present needs to be
> preserved. This is like one extra state that needs to be represented in
> the case of primitive values because null (no-value) is not in their
> value space. Such things would generally need to be unsettable, and
> enums are treated like primitives...


> John T.E. Timm wrote:
>> Ed,
>>
>> The model originated from a UML model that I created manually using an
>> XML schema and another domain-specific modeling language as a guide. I
>> was unable to use the schema directly as it was too large and complex
>> to get any sort of meaningful code generation without significant
>> modification and the standards organization that it came from has said
>> that the schema is not normative and encourages the use of their DSL
>> instead.
>>
>> As the model does contain a few other primitive types, perhaps I
>> should be using the isUnsettable = true for all attributes and deal
>> with the consequences in validation as a separate issue.
>>
>> Thanks,
>>
>> JT
>>
>> Ed Merks wrote:
>>
>>> John,
>>
>>> Did you model originate as an XML Schema?
>>
>>> Note that what you describe is true not just of enums but also of all
>>> primitive types...
>>
>>
>>> John T.E. Timm wrote:
>>>> One thing I forgot to mention about the use of isUnsettable =
>>>> true... If I do not use this option, then I am unable to
>>>> re-serialize any attribute that is present in the input document,
>>>> does not have a default literal value and is set to the first member
>>>> of the enumeration. I think isUnsettable = true may be critical to
>>>> accurately reserializing this type of attribute.
>>>>
>>>> Thanks,
>>>>
>>>> JT
>>>>
>>>> John T.E. Timm wrote:
>>>>
>>>>> Ed,
>>>>
>>>>> Sorry for the lack of a summary or "big picture" to frame my
>>>>> issues. This particular standard is "interesting" in terms of how
>>>>> it addresses attributes. They have optional attributes with fixed
>>>>> values and required attributes with default values (and everything
>>>>> in between). I will have a couple different varieties:
>>>>
>>>>> required attributes without default values
>>>>> required attributes with default values
>>>>> optional attributes without default values
>>>>> optional attributes with "fixed" values
>>>>
>>>>> My concern orginally came in modeling required attributes without
>>>>> default values. I was setting the value explicitly in code and it
>>>>> wasn't getting serialized. I found that this was because eIsSet was
>>>>> checking whether the value was different from default (which
>>>>> happens to be first member of enum). So if I set the value to first
>>>>> member of enum, I thought it was set, when in fact it wasn't. So, I
>>>>> went and changed all these types of attributes to isUnsettable =
>>>>> true. Voila! Problem fixed.
>>>>
>>>>> Now I have a scenario where the validator will not pick up an
>>>>> attribute value even if eGet != null because I am using
>>>>> isUnsettable = true. So I suppose this is the side-effect of the
>>>>> solution to my first issue. I see two possible solutions to this
>>>>> second issue: 1. iterate over content tree and explicitly set
>>>>> values that are unset with lower bound > 0 and default literal (my
>>>>> current solution) or 2. covert some attributes back to isUnsettable
>>>>> = false (i.e. if they have a default literal value). The first
>>>>> solution is bit of a hack and the second solution may be
>>>>> error-prone to maintain (if/when the standard changes). I would
>>>>> like to set the default literal value for everything and I agree
>>>>> that this really would be a pretty solid solution, but I don't
>>>>> think I have that option.
>>>>
>>>>> Thanks,
>>>>
>>>>> JT
>>>>
>>>>> Ed Merks wrote:
>>>>
>>>>>> John,
>>>>
>>>>>> Unfortunately the information you supply comes in tiny snippets
>>>>>> that make it hard for me to make sense of the whole picture.
>>>>>> Generally if an attribute is required in XML, you should expect to
>>>>>> be required to set/choose that value explicitly; certainly when
>>>>>> using DOM that would be required... And in XML Schema, only
>>>>>> optional attributes can have a default because of course, if the
>>>>>> attribute were required to be present in the XML instance then any
>>>>>> default in the model would never be applicable to any instance...
>>>>
>>>>
>>>>>> John T.E. Timm wrote:
>>>>>>> Ed,
>>>>>>>
>>>>>>> Thanks for the suggestion, but unfortunately, I have to live with
>>>>>>> the scenario that some attributes have default values and other
>>>>>>> do not as this is an implementation of a standard and I cannot
>>>>>>> make up or serialize default values if the standard does not
>>>>>>> explicitly allow me to do so for a given attribute.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> JT
>>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>>
>>>>>>>> John,
>>>>>>>
>>>>>>>> I suppose that setting an explicit default in each feature and
>>>>>>>> keeping the default during serialization would solve all your
>>>>>>>> problems...
>>>>>>>
>>>>>>>
>>>>>>>> John T.E. Timm wrote:
>>>>>>>>> I guess one possibility is to only make features unsettable if
>>>>>>>>> they do not have a default literal value. but then I am
>>>>>>>>> handling EEnums two different ways in my model and maintenance
>>>>>>>>> becomes an issue. There are a few hundred of these type of
>>>>>>>>> attributes.
>>>>>>>>>
>>>>>>>>> JT
>>>>>>>>>
>>>>>>>>> John T.E. Timm wrote:
>>>>>>>>>
>>>>>>>>>> I made these feature unsettable because of serialization and
>>>>>>>>>> circumstances where both conditions fail (is set or (keep
>>>>>>>>>> defaults and has default literal)) even if i explicitly set
>>>>>>>>>> value in code. This happens when feature isUnsettable = false,
>>>>>>>>>> does not have default literal and value is set in code to the
>>>>>>>>>> first member of the enum. This prompted me to make all enum
>>>>>>>>>> features isUnsettable = true. But the consequence of that,
>>>>>>>>>> seems to be validation.
>>>>>>>>>
>>>>>>>>>> Maybe I can't have it both ways where both serialization and
>>>>>>>>>> validation work in all cases...
>>>>>>>>>
>>>>>>>>>> JT
>>>>>>>>>
>>>>>>>>>> Ed Merks wrote:
>>>>>>>>>
>>>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>>>> Comments below.
>>>>>>>>>
>>>>>>>>>>> John T.E. Timm wrote:
>>>>>>>>>>>> Serialization looks at two things:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Whether or not the attribute is set
>>>>>>>>>>>> 2. Whether or not the attribute has a default literal value
>>>>>>>>>>>> (and keepDefaults == true which is set in the resource using
>>>>>>>>>>>> the KEEP_DEFAULT_CONTENT option)
>>>>>>>>>>>>
>>>>>>>>>>>> Validation seems to only look at:
>>>>>>>>>>> Validation works on in memory instances and cares not at all
>>>>>>>>>>> about XML serialization or any other serialization mechanism...
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Whether an attribute is required (lower bound > 0)
>>>>>>>>>>>> 2. Whether or not an attribute is set
>>>>>>>>>>>>
>>>>>>>>>>>> This being the case, if the attribute has lower bound > 0
>>>>>>>>>>>> but is not "set" then it will always fail validation.
>>>>>>>>>>>> Default literal value doesn't seem to come into the picture.
>>>>>>>>>>>> I ended up working around this by inspecting the content
>>>>>>>>>>>> tree and looking for attributes that are unset, have a
>>>>>>>>>>>> default value, and a lower bound > 0 and then setting the
>>>>>>>>>>>> attribute explicitly (eIsSet == true) in code. Here is a
>>>>>>>>>>>> snippet:
>>>>>>>>>>>>
>>>>>>>>>>>> if (!eObject.eIsSet(attribute) && attribute.getLowerBound()
>>>>>>>>>>>> > 0 && attribute.getDefaultValueLiteral() != null) {
>>>>>>>>>>>> if (attribute.isMany()) {
>>>>>>>>>>>> List<Object> list = (List<Object>)
>>>>>>>>>>>> eObject.eGet(attribute);
>>>>>>>>>>>> list.add(attribute.getDefaultValue());
>>>>>>>>>>>> } else {
>>>>>>>>>>>> eObject.eSet(attribute, attribute.getDefaultValue());
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> This solution seems to be a bit of a hack, however, so if
>>>>>>>>>>>> anyone knows of a better solution please let me know.
>>>>>>>>>>> Here's the actual logic:
>>>>>>>>>
>>>>>>>>>>> {
>>>>>>>>>>> if (eStructuralFeature.isUnsettable() ?
>>>>>>>>>>> !eObject.eIsSet(eStructuralFeature) :
>>>>>>>>>>> eObject.eGet(eStructuralFeature, false) == null)
>>>>>>>>>>> {
>>>>>>>>>
>>>>>>>>>>> So if a feature is unsettable, it definitely must be set,
>>>>>>>>>>> otherwise, it's sufficient that a non-null value is by the
>>>>>>>>>>> getter (which might be either the set value, or the default
>>>>>>>>>>> value). You've said nothing about unsettable features so far...
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> JT
>>>>>>>>>>>>
>>>>>>>>>>>> Boris Gruschko wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I just parsed your message header again. Apparently you set
>>>>>>>>>>>>> the deafult literal already.
>>>>>>>>>>>>
>>>>>>>>>>>>> Do you set the "Default Value Literal" to the value of
>>>>>>>>>>>>> "Value" attribute of the desired Enum Literal ?
>>>>>>>>>>>>
>>>>>>>>>>>>> I justed tested it and it validates without errors.
>>>>>>>>>>>>
>>>>>>>>>>>>> "Boris Gruschko" <boris.gruschko@sap.com> wrote in message
>>>>>>>>>>>>> news:h5bd3e$8dq$1@build.eclipse.org...
>>>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you can set the default value in your meta-model via
>>>>>>>>>>>>>> "Default Valu Literal" attribute. This works for
>>>>>>>>>>>>>> Enumeration typed attributes too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hope that helps and Cheers,
>>>>>>>>>>>>>> Boris
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "John T.E. Timm" <johntimm@us.ibm.com> wrote in message
>>>>>>>>>>>>>> news:c6b40cc4c3f364249cc203c2452b4f2f$1@www.eclipse.org...
>>>>>>>>>>>>>>> I have a situation where I would like to validate an
>>>>>>>>>>>>>>> EObject that has a default literal value for a required
>>>>>>>>>>>>>>> attribute (that is typed to an enumeration). Is there a
>>>>>>>>>>>>>>> way for me to get validation to succeed without having to
>>>>>>>>>>>>>>> explicitly set the value in code?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
Previous Topic:Multiple EMF meta-models in a single plugin
Next Topic:Delete elements in a model?
Goto Forum:
  


Current Time: Thu Dec 12 21:20:25 GMT 2019

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

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

Back to the top