Both models define "floatval" as an unsettable, lowerBound=0 attribute
of type EFloat. The input model actually is an ecore model as generated
by the XSDEcoreBuilder.

Here's the problem I'm facing: if the input value is unset, then the QVT
engine still ends up in assigning the intrinsic default value of float,
which is defined in
org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
result would have been that the lvalue remains unset.

Note this special handling is only done for primitive types. For
example, for all xs:integer based types in our XSD model it works,
because those are mapped to java.lang.BigInteger.

I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
or a QVT bug. I traced
QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
could not identify that QVT even cares for unset input attributes.

My expectation is that if some output is unSettable, it should not be
set, so specifying a QVTo assignment should be a compiler error; please
raise a Bugzilla.

If you omit the QVTo assignment, the only 'set' should be EMF's default
initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
this is even possible. If it's unsettable, any eSet should barf.

On the input side, I would not expect QVTo to take any notice of
isSettable. It's just a value source that happens to have a frozen default.

Regards

Ed Willink

On 17/01/2013 17:18, Marius Gröger wrote:
> Hello,
>
> given the following simple assignment:
>
> result.floatval := self.floatval;
>
> Both models define "floatval" as an unsettable, lowerBound=0 attribute
> of type EFloat. The input model actually is an ecore model as generated
> by the XSDEcoreBuilder.
>
> Here's the problem I'm facing: if the input value is unset, then the QVT
> engine still ends up in assigning the intrinsic default value of float,
> which is defined in
> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
> result would have been that the lvalue remains unset.
>
> Note this special handling is only done for primitive types. For
> example, for all xs:integer based types in our XSD model it works,
> because those are mapped to java.lang.BigInteger.
>
> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
> or a QVT bug. I traced
> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
> could not identify that QVT even cares for unset input attributes.
>
> TIA for any insights!
>
> Marius

thanks for your answer. Reading it made me realize that I misunderstood
the meaning of "unsettable". I was under the impression that it means
"can be unset", but it really means "cannot be set".

This misunderstanding led me to a false description of the issue. So
here I go again with the corrected description:

Given the following simple assignment:

result.floatval := self.floatval;

Both models define "floatval" as a settable, lowerBound=0 attribute
of type EFloat. The input model actually is an ecore model as generated
by the XSDEcoreBuilder.

Here's the problem I'm facing: if the input value is unset, then the QVT
engine still ends up in assigning the intrinsic default value of float,
which is defined in
org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
result would have been that the lvalue remains unset, because the rvalue
is unset as well.

TIA
Marius

On 17.01.2013 20:52, Ed Willink wrote:
> Hi
>
> My expectation is that if some output is unSettable, it should not be
> set, so specifying a QVTo assignment should be a compiler error; please
> raise a Bugzilla.
>
> If you omit the QVTo assignment, the only 'set' should be EMF's default
> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
> this is even possible. If it's unsettable, any eSet should barf.
>
> On the input side, I would not expect QVTo to take any notice of
> isSettable. It's just a value source that happens to have a frozen default.
>
> Regards
>
> Ed Willink
>
> On 17/01/2013 17:18, Marius Gröger wrote:
>> Hello,
>>
>> given the following simple assignment:
>>
>> result.floatval := self.floatval;
>>
>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>> of type EFloat. The input model actually is an ecore model as generated
>> by the XSDEcoreBuilder.
>>
>> Here's the problem I'm facing: if the input value is unset, then the QVT
>> engine still ends up in assigning the intrinsic default value of float,
>> which is defined in
>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>> result would have been that the lvalue remains unset.
>>
>> Note this special handling is only done for primitive types. For
>> example, for all xs:integer based types in our XSD model it works,
>> because those are mapped to java.lang.BigInteger.
>>
>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>> or a QVT bug. I traced
>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
>> could not identify that QVT even cares for unset input attributes.
>>
>> TIA for any insights!
>>
>> Marius
>

No. Unset, means that it has not been explicitly set and so retains its
initial value. It does not mean that it contains a distinct out-of-band
value. So a transformation should indeed transfer this value. Just
possibly in an Eclipse tool if the transferred value is identical to the
default value the transfer could be done without actually setting the
default explicitly.

However unset is an Ecore rather than EMOF concept, so there is no OMG
specification for this in OCL or QVT.

If unset was supported, one would need to define whether an update
transformation sets the unchanged values, in which case there could be
an inconsistency between a created output and an unchanged refreshed
output. Would need some careful study.

So no bug. QVTo like many tools is free to perform redundant sets when
creating EObjects.

Regards

Ed Willink

On 18/01/2013 07:41, Marius Gröger wrote:
> Hi Ed,
>
> thanks for your answer. Reading it made me realize that I misunderstood
> the meaning of "unsettable". I was under the impression that it means
> "can be unset", but it really means "cannot be set".
>
> This misunderstanding led me to a false description of the issue. So
> here I go again with the corrected description:
>
> Given the following simple assignment:
>
> result.floatval := self.floatval;
>
> Both models define "floatval" as a settable, lowerBound=0 attribute
> of type EFloat. The input model actually is an ecore model as generated
> by the XSDEcoreBuilder.
>
> Here's the problem I'm facing: if the input value is unset, then the QVT
> engine still ends up in assigning the intrinsic default value of float,
> which is defined in
> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
> result would have been that the lvalue remains unset, because the rvalue
> is unset as well.
>
> TIA
> Marius
>
> On 17.01.2013 20:52, Ed Willink wrote:
>> Hi
>>
>> My expectation is that if some output is unSettable, it should not be
>> set, so specifying a QVTo assignment should be a compiler error; please
>> raise a Bugzilla.
>>
>> If you omit the QVTo assignment, the only 'set' should be EMF's default
>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>> this is even possible. If it's unsettable, any eSet should barf.
>>
>> On the input side, I would not expect QVTo to take any notice of
>> isSettable. It's just a value source that happens to have a frozen default.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 17/01/2013 17:18, Marius Gröger wrote:
>>> Hello,
>>>
>>> given the following simple assignment:
>>>
>>> result.floatval := self.floatval;
>>>
>>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>>> of type EFloat. The input model actually is an ecore model as generated
>>> by the XSDEcoreBuilder.
>>>
>>> Here's the problem I'm facing: if the input value is unset, then the QVT
>>> engine still ends up in assigning the intrinsic default value of float,
>>> which is defined in
>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>>> result would have been that the lvalue remains unset.
>>>
>>> Note this special handling is only done for primitive types. For
>>> example, for all xs:integer based types in our XSD model it works,
>>> because those are mapped to java.lang.BigInteger.
>>>
>>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>>> or a QVT bug. I traced
>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger bug
>>> could not identify that QVT even cares for unset input attributes.
>>>
>>> TIA for any insights!
>>>
>>> Marius

thanks for your explanation. In the meantime I have done some reading
and found that my initial understanding "unset" was correct after all:
it means the value has not been assigned a value.

So my issue boils down to the fact that EMF, for primitive type, always
has an intrinsic default value. It is this value that QVT will then
transfer. For non-primitive types, the value is also transfered, but
that value is null and so the output attribute remains being unset.

I think I will take it to the EMF group to find out how to best handle this.

Thanks again
Marius

On 18.01.2013 09:17, Ed Willink wrote:
> Hi
>
> No. Unset, means that it has not been explicitly set and so retains its
> initial value. It does not mean that it contains a distinct out-of-band
> value. So a transformation should indeed transfer this value. Just
> possibly in an Eclipse tool if the transferred value is identical to the
> default value the transfer could be done without actually setting the
> default explicitly.
>
> However unset is an Ecore rather than EMOF concept, so there is no OMG
> specification for this in OCL or QVT.
>
> If unset was supported, one would need to define whether an update
> transformation sets the unchanged values, in which case there could be
> an inconsistency between a created output and an unchanged refreshed
> output. Would need some careful study.
>
> So no bug. QVTo like many tools is free to perform redundant sets when
> creating EObjects.
>
> Regards
>
> Ed Willink
>
>
> On 18/01/2013 07:41, Marius Gröger wrote:
>> Hi Ed,
>>
>> thanks for your answer. Reading it made me realize that I misunderstood
>> the meaning of "unsettable". I was under the impression that it means
>> "can be unset", but it really means "cannot be set".
>>
>> This misunderstanding led me to a false description of the issue. So
>> here I go again with the corrected description:
>>
>> Given the following simple assignment:
>>
>> result.floatval := self.floatval;
>>
>> Both models define "floatval" as a settable, lowerBound=0 attribute
>> of type EFloat. The input model actually is an ecore model as generated
>> by the XSDEcoreBuilder.
>>
>> Here's the problem I'm facing: if the input value is unset, then the QVT
>> engine still ends up in assigning the intrinsic default value of float,
>> which is defined in
>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>> result would have been that the lvalue remains unset, because the rvalue
>> is unset as well.
>>
>> TIA
>> Marius
>>
>> On 17.01.2013 20:52, Ed Willink wrote:
>>> Hi
>>>
>>> My expectation is that if some output is unSettable, it should not be
>>> set, so specifying a QVTo assignment should be a compiler error; please
>>> raise a Bugzilla.
>>>
>>> If you omit the QVTo assignment, the only 'set' should be EMF's default
>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>> this is even possible. If it's unsettable, any eSet should barf.
>>>
>>> On the input side, I would not expect QVTo to take any notice of
>>> isSettable. It's just a value source that happens to have a frozen
>>> default.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>> Hello,
>>>>
>>>> given the following simple assignment:
>>>>
>>>> result.floatval := self.floatval;
>>>>
>>>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>>>> of type EFloat. The input model actually is an ecore model as generated
>>>> by the XSDEcoreBuilder.
>>>>
>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>> QVT
>>>> engine still ends up in assigning the intrinsic default value of float,
>>>> which is defined in
>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>> expected
>>>> result would have been that the lvalue remains unset.
>>>>
>>>> Note this special handling is only done for primitive types. For
>>>> example, for all xs:integer based types in our XSD model it works,
>>>> because those are mapped to java.lang.BigInteger.
>>>>
>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>>>> or a QVT bug. I traced
>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>> bug
>>>> could not identify that QVT even cares for unset input attributes.
>>>>
>>>> TIA for any insights!
>>>>
>>>> Marius
>

It is not the type that is unset; it is the reference to the type that
is unset, so there should be no difference for primitive types. EMF
maintains a distinct out-of-band is_set eFlags bit for the case where
there is no in-band value that can be used.

QVTo has no specification for this bit.

If explicit-set/default is so important to you, I suggest that you model
it explicitly rather than rely on under-specified implementation details.

Regards

Ed Willink

On 18/01/2013 08:58, Marius Gröger wrote:
> Hello Ed,
>
> thanks for your explanation. In the meantime I have done some reading
> and found that my initial understanding "unset" was correct after all:
> it means the value has not been assigned a value.
>
> So my issue boils down to the fact that EMF, for primitive type, always
> has an intrinsic default value. It is this value that QVT will then
> transfer. For non-primitive types, the value is also transfered, but
> that value is null and so the output attribute remains being unset.
>
> I think I will take it to the EMF group to find out how to best handle this.
>
> Thanks again
> Marius
>
> On 18.01.2013 09:17, Ed Willink wrote:
>> Hi
>>
>> No. Unset, means that it has not been explicitly set and so retains its
>> initial value. It does not mean that it contains a distinct out-of-band
>> value. So a transformation should indeed transfer this value. Just
>> possibly in an Eclipse tool if the transferred value is identical to the
>> default value the transfer could be done without actually setting the
>> default explicitly.
>>
>> However unset is an Ecore rather than EMOF concept, so there is no OMG
>> specification for this in OCL or QVT.
>>
>> If unset was supported, one would need to define whether an update
>> transformation sets the unchanged values, in which case there could be
>> an inconsistency between a created output and an unchanged refreshed
>> output. Would need some careful study.
>>
>> So no bug. QVTo like many tools is free to perform redundant sets when
>> creating EObjects.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 18/01/2013 07:41, Marius Gröger wrote:
>>> Hi Ed,
>>>
>>> thanks for your answer. Reading it made me realize that I misunderstood
>>> the meaning of "unsettable". I was under the impression that it means
>>> "can be unset", but it really means "cannot be set".
>>>
>>> This misunderstanding led me to a false description of the issue. So
>>> here I go again with the corrected description:
>>>
>>> Given the following simple assignment:
>>>
>>> result.floatval := self.floatval;
>>>
>>> Both models define "floatval" as a settable, lowerBound=0 attribute
>>> of type EFloat. The input model actually is an ecore model as generated
>>> by the XSDEcoreBuilder.
>>>
>>> Here's the problem I'm facing: if the input value is unset, then the QVT
>>> engine still ends up in assigning the intrinsic default value of float,
>>> which is defined in
>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The expected
>>> result would have been that the lvalue remains unset, because the rvalue
>>> is unset as well.
>>>
>>> TIA
>>> Marius
>>>
>>> On 17.01.2013 20:52, Ed Willink wrote:
>>>> Hi
>>>>
>>>> My expectation is that if some output is unSettable, it should not be
>>>> set, so specifying a QVTo assignment should be a compiler error; please
>>>> raise a Bugzilla.
>>>>
>>>> If you omit the QVTo assignment, the only 'set' should be EMF's default
>>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>>> this is even possible. If it's unsettable, any eSet should barf.
>>>>
>>>> On the input side, I would not expect QVTo to take any notice of
>>>> isSettable. It's just a value source that happens to have a frozen
>>>> default.
>>>>
>>>> Regards
>>>>
>>>> Ed Willink
>>>>
>>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>>> Hello,
>>>>>
>>>>> given the following simple assignment:
>>>>>
>>>>> result.floatval := self.floatval;
>>>>>
>>>>> Both models define "floatval" as an unsettable, lowerBound=0 attribute
>>>>> of type EFloat. The input model actually is an ecore model as generated
>>>>> by the XSDEcoreBuilder.
>>>>>
>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>> QVT
>>>>> engine still ends up in assigning the intrinsic default value of float,
>>>>> which is defined in
>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>> expected
>>>>> result would have been that the lvalue remains unset.
>>>>>
>>>>> Note this special handling is only done for primitive types. For
>>>>> example, for all xs:integer based types in our XSD model it works,
>>>>> because those are mapped to java.lang.BigInteger.
>>>>>
>>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF bug,
>>>>> or a QVT bug. I traced
>>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>>> bug
>>>>> could not identify that QVT even cares for unset input attributes.
>>>>>
>>>>> TIA for any insights!
>>>>>
>>>>> Marius

I'm afraid explicitly modeling set/unset would be overly complicate the
XSD model. The XML instance is perfectly able to represent the unset
case, and so is my internal EMF model. It's just a shame that during the
QVT conversion, EMF sneaks in an intrinsic default for all primitive
types. I'm currently looking into changing this behavior in EMF's
XSDEcoreBuilder, but it doesn't look very promising.

Marius

On 18.01.2013 10:55, Ed Willink wrote:
> Hi
>
> It is not the type that is unset; it is the reference to the type that
> is unset, so there should be no difference for primitive types. EMF
> maintains a distinct out-of-band is_set eFlags bit for the case where
> there is no in-band value that can be used.
>
> QVTo has no specification for this bit.
>
> If explicit-set/default is so important to you, I suggest that you model
> it explicitly rather than rely on under-specified implementation details.
>
> Regards
>
> Ed Willink
>
>
> On 18/01/2013 08:58, Marius Gröger wrote:
>> Hello Ed,
>>
>> thanks for your explanation. In the meantime I have done some reading
>> and found that my initial understanding "unset" was correct after all:
>> it means the value has not been assigned a value.
>>
>> So my issue boils down to the fact that EMF, for primitive type, always
>> has an intrinsic default value. It is this value that QVT will then
>> transfer. For non-primitive types, the value is also transfered, but
>> that value is null and so the output attribute remains being unset.
>>
>> I think I will take it to the EMF group to find out how to best handle
>> this.
>>
>> Thanks again
>> Marius
>>
>> On 18.01.2013 09:17, Ed Willink wrote:
>>> Hi
>>>
>>> No. Unset, means that it has not been explicitly set and so retains its
>>> initial value. It does not mean that it contains a distinct out-of-band
>>> value. So a transformation should indeed transfer this value. Just
>>> possibly in an Eclipse tool if the transferred value is identical to the
>>> default value the transfer could be done without actually setting the
>>> default explicitly.
>>>
>>> However unset is an Ecore rather than EMOF concept, so there is no OMG
>>> specification for this in OCL or QVT.
>>>
>>> If unset was supported, one would need to define whether an update
>>> transformation sets the unchanged values, in which case there could be
>>> an inconsistency between a created output and an unchanged refreshed
>>> output. Would need some careful study.
>>>
>>> So no bug. QVTo like many tools is free to perform redundant sets when
>>> creating EObjects.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>>
>>> On 18/01/2013 07:41, Marius Gröger wrote:
>>>> Hi Ed,
>>>>
>>>> thanks for your answer. Reading it made me realize that I misunderstood
>>>> the meaning of "unsettable". I was under the impression that it means
>>>> "can be unset", but it really means "cannot be set".
>>>>
>>>> This misunderstanding led me to a false description of the issue. So
>>>> here I go again with the corrected description:
>>>>
>>>> Given the following simple assignment:
>>>>
>>>> result.floatval := self.floatval;
>>>>
>>>> Both models define "floatval" as a settable, lowerBound=0 attribute
>>>> of type EFloat. The input model actually is an ecore model as generated
>>>> by the XSDEcoreBuilder.
>>>>
>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>> QVT
>>>> engine still ends up in assigning the intrinsic default value of float,
>>>> which is defined in
>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>> expected
>>>> result would have been that the lvalue remains unset, because the
>>>> rvalue
>>>> is unset as well.
>>>>
>>>> TIA
>>>> Marius
>>>>
>>>> On 17.01.2013 20:52, Ed Willink wrote:
>>>>> Hi
>>>>>
>>>>> My expectation is that if some output is unSettable, it should not be
>>>>> set, so specifying a QVTo assignment should be a compiler error;
>>>>> please
>>>>> raise a Bugzilla.
>>>>>
>>>>> If you omit the QVTo assignment, the only 'set' should be EMF's
>>>>> default
>>>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>>>> this is even possible. If it's unsettable, any eSet should barf.
>>>>>
>>>>> On the input side, I would not expect QVTo to take any notice of
>>>>> isSettable. It's just a value source that happens to have a frozen
>>>>> default.
>>>>>
>>>>> Regards
>>>>>
>>>>> Ed Willink
>>>>>
>>>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>>>> Hello,
>>>>>>
>>>>>> given the following simple assignment:
>>>>>>
>>>>>> result.floatval := self.floatval;
>>>>>>
>>>>>> Both models define "floatval" as an unsettable, lowerBound=0
>>>>>> attribute
>>>>>> of type EFloat. The input model actually is an ecore model as
>>>>>> generated
>>>>>> by the XSDEcoreBuilder.
>>>>>>
>>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>>> QVT
>>>>>> engine still ends up in assigning the intrinsic default value of
>>>>>> float,
>>>>>> which is defined in
>>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>>> expected
>>>>>> result would have been that the lvalue remains unset.
>>>>>>
>>>>>> Note this special handling is only done for primitive types. For
>>>>>> example, for all xs:integer based types in our XSD model it works,
>>>>>> because those are mapped to java.lang.BigInteger.
>>>>>>
>>>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF
>>>>>> bug,
>>>>>> or a QVT bug. I traced
>>>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>>>> bug
>>>>>> could not identify that QVT even cares for unset input attributes.
>>>>>>
>>>>>> TIA for any insights!
>>>>>>
>>>>>> Marius
>

I can see a QVTo change on efficiency grounds to the effect that every
eSet to the output model is guarded by an if-necessary test.

This would avoid numerous redundant notifications for the in-place
update usage.

This would also solve your immediate problem, but probably then provoke
the opposite; output values that just happen to be right by default
would not be explicitly set.

If so then QVTo may be needs four eSet modes:
- always eSet
- always eSet unless value is correct and source is explictly unset
- only eSet if necessary to change a value
- only eSet if necessary to change a value or source is explicitly set

Since the source is an arbitrary OCL expression, special casing the
trivial PropertyCallExp makes me uncomfortable, and why can't you
control unset for more complex cases?

Surely you can control unset on the output by wrapping the assignment in
an imperative if? Then you just need a helper function to allow you to
test whether a source value is unset.

Regards

Ed Willink

On 18/01/2013 12:36, Marius Gröger wrote:
> Hello,
>
> I'm afraid explicitly modeling set/unset would be overly complicate the
> XSD model. The XML instance is perfectly able to represent the unset
> case, and so is my internal EMF model. It's just a shame that during the
> QVT conversion, EMF sneaks in an intrinsic default for all primitive
> types. I'm currently looking into changing this behavior in EMF's
> XSDEcoreBuilder, but it doesn't look very promising.
>
> Marius
>
> On 18.01.2013 10:55, Ed Willink wrote:
>> Hi
>>
>> It is not the type that is unset; it is the reference to the type that
>> is unset, so there should be no difference for primitive types. EMF
>> maintains a distinct out-of-band is_set eFlags bit for the case where
>> there is no in-band value that can be used.
>>
>> QVTo has no specification for this bit.
>>
>> If explicit-set/default is so important to you, I suggest that you model
>> it explicitly rather than rely on under-specified implementation details.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 18/01/2013 08:58, Marius Gröger wrote:
>>> Hello Ed,
>>>
>>> thanks for your explanation. In the meantime I have done some reading
>>> and found that my initial understanding "unset" was correct after all:
>>> it means the value has not been assigned a value.
>>>
>>> So my issue boils down to the fact that EMF, for primitive type, always
>>> has an intrinsic default value. It is this value that QVT will then
>>> transfer. For non-primitive types, the value is also transfered, but
>>> that value is null and so the output attribute remains being unset.
>>>
>>> I think I will take it to the EMF group to find out how to best handle
>>> this.
>>>
>>> Thanks again
>>> Marius
>>>
>>> On 18.01.2013 09:17, Ed Willink wrote:
>>>> Hi
>>>>
>>>> No. Unset, means that it has not been explicitly set and so retains its
>>>> initial value. It does not mean that it contains a distinct out-of-band
>>>> value. So a transformation should indeed transfer this value. Just
>>>> possibly in an Eclipse tool if the transferred value is identical to the
>>>> default value the transfer could be done without actually setting the
>>>> default explicitly.
>>>>
>>>> However unset is an Ecore rather than EMOF concept, so there is no OMG
>>>> specification for this in OCL or QVT.
>>>>
>>>> If unset was supported, one would need to define whether an update
>>>> transformation sets the unchanged values, in which case there could be
>>>> an inconsistency between a created output and an unchanged refreshed
>>>> output. Would need some careful study.
>>>>
>>>> So no bug. QVTo like many tools is free to perform redundant sets when
>>>> creating EObjects.
>>>>
>>>> Regards
>>>>
>>>> Ed Willink
>>>>
>>>>
>>>> On 18/01/2013 07:41, Marius Gröger wrote:
>>>>> Hi Ed,
>>>>>
>>>>> thanks for your answer. Reading it made me realize that I misunderstood
>>>>> the meaning of "unsettable". I was under the impression that it means
>>>>> "can be unset", but it really means "cannot be set".
>>>>>
>>>>> This misunderstanding led me to a false description of the issue. So
>>>>> here I go again with the corrected description:
>>>>>
>>>>> Given the following simple assignment:
>>>>>
>>>>> result.floatval := self.floatval;
>>>>>
>>>>> Both models define "floatval" as a settable, lowerBound=0 attribute
>>>>> of type EFloat. The input model actually is an ecore model as generated
>>>>> by the XSDEcoreBuilder.
>>>>>
>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>> QVT
>>>>> engine still ends up in assigning the intrinsic default value of float,
>>>>> which is defined in
>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>> expected
>>>>> result would have been that the lvalue remains unset, because the
>>>>> rvalue
>>>>> is unset as well.
>>>>>
>>>>> TIA
>>>>> Marius
>>>>>
>>>>> On 17.01.2013 20:52, Ed Willink wrote:
>>>>>> Hi
>>>>>>
>>>>>> My expectation is that if some output is unSettable, it should not be
>>>>>> set, so specifying a QVTo assignment should be a compiler error;
>>>>>> please
>>>>>> raise a Bugzilla.
>>>>>>
>>>>>> If you omit the QVTo assignment, the only 'set' should be EMF's
>>>>>> default
>>>>>> initialization. If QVTo zaps it please raise a Bugzilla. I'm not sure
>>>>>> this is even possible. If it's unsettable, any eSet should barf.
>>>>>>
>>>>>> On the input side, I would not expect QVTo to take any notice of
>>>>>> isSettable. It's just a value source that happens to have a frozen
>>>>>> default.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Ed Willink
>>>>>>
>>>>>> On 17/01/2013 17:18, Marius Gröger wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> given the following simple assignment:
>>>>>>>
>>>>>>> result.floatval := self.floatval;
>>>>>>>
>>>>>>> Both models define "floatval" as an unsettable, lowerBound=0
>>>>>>> attribute
>>>>>>> of type EFloat. The input model actually is an ecore model as
>>>>>>> generated
>>>>>>> by the XSDEcoreBuilder.
>>>>>>>
>>>>>>> Here's the problem I'm facing: if the input value is unset, then the
>>>>>>> QVT
>>>>>>> engine still ends up in assigning the intrinsic default value of
>>>>>>> float,
>>>>>>> which is defined in
>>>>>>> org.eclipse.emf.ecore.impl.EDataTypeImpl.getDefaultValue(). The
>>>>>>> expected
>>>>>>> result would have been that the lvalue remains unset.
>>>>>>>
>>>>>>> Note this special handling is only done for primitive types. For
>>>>>>> example, for all xs:integer based types in our XSD model it works,
>>>>>>> because those are mapped to java.lang.BigInteger.
>>>>>>>
>>>>>>> I'm not sure yet if this is a missunderstanding on my part, an EMF
>>>>>>> bug,
>>>>>>> or a QVT bug. I traced
>>>>>>> QvtOperationalEvaluationVisitorImpl.visitAssignExp() in the debugger
>>>>>>> bug
>>>>>>> could not identify that QVT even cares for unset input attributes.
>>>>>>>
>>>>>>> TIA for any insights!
>>>>>>>
>>>>>>> Marius

On 18.01.2013 14:00, Ed Willink wrote:
> Surely you can control unset on the output by wrapping the assignment in
> an imperative if? Then you just need a helper function to allow you to
> test whether a source value is unset.

Meaning to analyse the source as an EObject and checking eIsSet()?
Probably, but it would really mess up the QVT code a lot. And I really
only see this issue with primitive floats.

I just posted a work-around on e.t.emf in the thread 'Annoying intrinsic
default values for primitive types'. That solution concerns XSD models.
Regular Ecore models won't be affected by this as long as all values are
put into custom EDataTypes, ie. if EInt, EFloat etc are avoided.

On 18.01.2013 15:55, Alan McMorran wrote:
> I ran into this problem and my solution is to sort of cheat a bit and
> add a Helper method:

Thanks for sharing this. TBH, I was aware that this can be solved like
this, but I don't really like having to actively remember writing that
if-isSet-then-set-endif clause everytime I assign such a value. What's
more, we are working on those transformations in a team so everybody has
to remember.

To recap: if you use custom datatypes in your EMF models that point to
java.lang.Float etc., then attributes with these types can very well be
unset and will deliver "null" when QVT calls eGet(). No problem here,
because when QVT subsequently eSet()s this "null" value to the output
variable, everything behaves as expected.

It's _only_ primitive types (EFloat etc. and --in my case-- xs:float
from an originating XSD) which will magically deliver the intrinsic
default even when they were never explicitly assigned. While I
understand Ed Merck's argument that intrinsic values just always have a
default, I like my models to be truely unsettable and returning "null"
if so.