Eclipse Community Forums: GMF (Graphical Modeling Framework) » Feature or Bug? Empty properties with multiplicities of n are created as attribute in the correspond

Home » Modeling » GMF (Graphical Modeling Framework) » Feature or Bug? Empty properties with multiplicities of n are created as attribute in the correspond

Feature or Bug? Empty properties with multiplicities of n are created as attribute in the correspond [message #211125]

Thu, 13 November 2008 07:16

Eclipse User

Originally posted by: ralf.buschermoehle.informatik.uni-oldenburg.de

Hello,

See <Topic> ... when an element is e.g. moved in the GMF editor, *unsed*
properties are stored in the corresponding domain model xml file as
attributes even if they have been modeled with upper multiplicities of
"-1" in the ecore. They should be stored as

<featureX>

<featureX/>

but they are stored as

<... featureX="">

Then the generated EMF editor says ...

"org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'FeatureX'
not found."

.... when I try to open the domain file.

It is totally correct stored inside tags when I *set* the values in the
GMF editor.

1.) Why are features stored at all when I did not set them?

1.a.) Can this be avoided (the storage) and how?

2.) If not (1.a.) can I tell GMF to store tags instead of attributes in
the domain model file?

Greetings,

Ralf

P.S. I tried GMF gmf 2.1.2 and 2.2.0M3 (with corresponding emf versions).

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211136 is a reply to message #211125]

Thu, 13 November 2008 08:23

Eclipse User

Ralf,

Comments below.

Ralf Buschermoehle wrote:
> Hello,
>
> See <Topic> ... when an element is e.g. moved in the GMF editor,
> *unsed* properties are stored in the corresponding domain model xml
> file as attributes even if they have been modeled with upper
> multiplicities of "-1" in the ecore. They should be stored as
>
> <featureX>
>
> <featureX/>
>
> but they are stored as
>
> <... featureX="">
I'd expect this only if featureX is an unsettable feature. In that
case, the feature can be considered set even if the list is empty, and
what you show above is how this "set empty list" is represented in XMI.
It can't be represented at all in an XML (non-XMI) serialization.
>
> Then the generated EMF editor says ...
>
> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
> 'FeatureX' not found."
>
> ... when I try to open the domain file.
Are you using the same resource implementation with the same options in
each case?
>
> It is totally correct stored inside tags when I *set* the values in
> the GMF editor.
>
> 1.) Why are features stored at all when I did not set them?
>
> 1.a.) Can this be avoided (the storage) and how?
>
> 2.) If not (1.a.) can I tell GMF to store tags instead of attributes
> in the domain model file?
Extended metadata annotations can be used to direct the serialization
style, but it should always be possible to read in what was written out
assuming the same configured implementations are used in each case.
>
> Greetings,
>
> Ralf
>
> P.S. I tried GMF gmf 2.1.2 and 2.2.0M3 (with corresponding emf versions).

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211144 is a reply to message #211136]

Thu, 13 November 2008 09:06

Eclipse User

Originally posted by: ralf.buschermoehle.informatik.uni-oldenburg.de

Hi Ed,

thanks (as always) for the fast reply! Comments below.

Ed Merks wrote:
> Ralf,
>
> Comments below.
>
>
> Ralf Buschermoehle wrote:
>> Hello,
>>
>> See <Topic> ... when an element is e.g. moved in the GMF editor,
>> *unsed* properties are stored in the corresponding domain model xml
>> file as attributes even if they have been modeled with upper
>> multiplicities of "-1" in the ecore. They should be stored as
>>
>> <featureX>
>>
>> <featureX/>
>>
>> but they are stored as
>>
>> <... featureX="">
> I'd expect this only if featureX is an unsettable feature.

Hm, no ... featureX is defined in the ecore as

<eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
unique="false"
upperBound="-1" eType="ecore:EDataType
http://www.eclipse.org/emf/2003/XMLType#//String"
defaultValueLiteral="">
<eAnnotations
source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="element"/>
<details key="name" value="featureX"/>
</eAnnotations>
</eStructuralFeatures>

> In that
> case, the feature can be considered set even if the list is empty, and
> what you show above is how this "set empty list" is represented in XMI.
> It can't be represented at all in an XML (non-XMI) serialization.

Yes, if I delete the attributes everything is fine (or set value(s)).

>>
>> Then the generated EMF editor says ...
>>
>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>> 'FeatureX' not found."
>>
>> ... when I try to open the domain file.
> Are you using the same resource implementation with the same options in
> each case?

Yes. If you are interested I can send you the model files (emf/gmf/example)?

>> It is totally correct stored inside tags when I *set* the values in
>> the GMF editor.
>>
>> 1.) Why are features stored at all when I did not set them?
>>
>> 1.a.) Can this be avoided (the storage) and how?
>>
>> 2.) If not (1.a.) can I tell GMF to store tags instead of attributes
>> in the domain model file?
> Extended metadata annotations can be used to direct the serialization
> style, but it should always be possible to read in what was written out
> assuming the same configured implementations are used in each case.

I assumed/hoped - but then it's even stranger ... ? Hmm..

Greetings,

Ralf

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211150 is a reply to message #211144]

Thu, 13 November 2008 09:27

Eclipse User

This is a multi-part message in MIME format.
--------------010103020302010808080805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ralf,

Comments below.

Ralf Buschermoehle wrote:
> Hi Ed,
>
> thanks (as always) for the fast reply! Comments below.
>
> Ed Merks wrote:
>> Ralf,
>>
>> Comments below.
>>
>>
>> Ralf Buschermoehle wrote:
>>> Hello,
>>>
>>> See <Topic> ... when an element is e.g. moved in the GMF editor,
>>> *unsed* properties are stored in the corresponding domain model xml
>>> file as attributes even if they have been modeled with upper
>>> multiplicities of "-1" in the ecore. They should be stored as
>>>
>>> <featureX>
>>>
>>> <featureX/>
>>>
>>> but they are stored as
>>>
>>> <... featureX="">
>> I'd expect this only if featureX is an unsettable feature.
>
> Hm, no ... featureX is defined in the ecore as
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
> unique="false"
> upperBound="-1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String"
> defaultValueLiteral="">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="element"/>
> <details key="name" value="featureX"/>
> </eAnnotations>
> </eStructuralFeatures>
It really looks to me like XMLSaveImpl.saveManyEmpty is being called.
Which happens for unsettable features. Oh and I see, it will happen for
things with a default value as well.

protected boolean shouldSaveFeature(EObject o, EStructuralFeature f)
{
return o.eIsSet(f) || keepDefaults && f.getDefaultValueLiteral()
!= null;
}

Probably this default value is kind of bogus?
>
>> In that case, the feature can be considered set even if the list is
>> empty, and what you show above is how this "set empty list" is
>> represented in XMI. It can't be represented at all in an XML
>> (non-XMI) serialization.
>
> Yes, if I delete the attributes everything is fine (or set value(s)).
>
>>>
>>> Then the generated EMF editor says ...
>>>
>>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>>> 'FeatureX' not found."
>>>
>>> ... when I try to open the domain file.
>> Are you using the same resource implementation with the same options
>> in each case?
>
> Yes. If you are interested I can send you the model files
> (emf/gmf/example)?
>
>>> It is totally correct stored inside tags when I *set* the values in
>>> the GMF editor.
>>>
>>> 1.) Why are features stored at all when I did not set them?
>>>
>>> 1.a.) Can this be avoided (the storage) and how?
>>>
>>> 2.) If not (1.a.) can I tell GMF to store tags instead of attributes
>>> in the domain model file?
>> Extended metadata annotations can be used to direct the serialization
>> style, but it should always be possible to read in what was written
>> out assuming the same configured implementations are used in each case.
>
> I assumed/hoped - but then it's even stranger ... ? Hmm..
Maybe you've just hit a case I've not seen before. Not sure how you
ended up with this model. Did it start as a schema? The default value
of "" seems odd for a repeating element...
>
> Greetings,
>
> Ralf

--------------010103020302010808080805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ralf, 
 
Comments below. 
 
Ralf Buschermoehle wrote:
<blockquote cite="mid:gfhc9u$ert$1@build.eclipse.org" type="cite">Hi
Ed,
 
 
thanks (as always) for the fast reply! Comments below.
 
 
Ed Merks wrote:
 
<blockquote type="cite">Ralf,
 
 
Comments below.
 
 
 
Ralf Buschermoehle wrote:
 
<blockquote type="cite">Hello,
 
 
See <Topic> ... when an element is e.g. moved in the GMF editor,
*unsed* properties are stored in the corresponding domain model xml
file as attributes even if they have been modeled with upper
multiplicities of "-1" in the ecore. They should be stored as
 
 
<featureX>
 
 
<featureX/>
 
 
but they are stored as
 
 
<... featureX="">
 
</blockquote>
I'd expect this only if featureX is an unsettable feature. </blockquote>
 
Hm, no ... featureX is defined in the ecore as
 
 
<eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
unique="false"
 
         upperBound="-1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2003/XMLType#//String">http://www.eclipse.org/emf/2003/XMLType#//String</a>"
 
         defaultValueLiteral="">
 
      <eAnnotations
source=<a class="moz-txt-link-rfc2396E" href="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">"http:///org/eclipse/emf/ecore/util/ExtendedMetaData"</a>>
 
         <details key="kind" value="element"/>
 
         <details key="name" value="featureX"/>
 
      </eAnnotations>
 
    </eStructuralFeatures>
 
</blockquote>
It really looks to me like XMLSaveImpl.saveManyEmpty is being called. 
Which happens for unsettable features.  Oh and I see, it will happen
for things with a default value as well. 
<blockquote>  protected boolean shouldSaveFeature(EObject o,
EStructuralFeature f) 
  { 
    return o.eIsSet(f) || keepDefaults &&
f.getDefaultValueLiteral() != null; 
  } 
</blockquote>
Probably this default value is kind of bogus? 
<blockquote cite="mid:gfhc9u$ert$1@build.eclipse.org" type="cite"> 
<blockquote type="cite">In that case, the feature can be considered
set even if the list is empty, and what you show above is how this "set
empty list" is represented in XMI.  It can't be represented at all in
an XML (non-XMI) serialization.
 
</blockquote>
 
Yes, if I delete the attributes everything is fine (or set value(s)).
 
 
<blockquote type="cite">
<blockquote type="cite"> 
Then the generated EMF editor says ...
 
 
"org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'FeatureX'
not found."
 
 
.... when I try to open the domain file.
 
</blockquote>
Are you using the same resource implementation with the same options in
each case?
 
</blockquote>
 
Yes. If you are interested I can send you the model files
(emf/gmf/example)?
 
 
<blockquote type="cite">
<blockquote type="cite">It is totally correct stored inside tags
when I *set* the values in the GMF editor.
 
 
1.) Why are features stored at all when I did not set them?
 
 
1.a.) Can this be avoided (the storage) and how?
 
 
2.) If not (1.a.) can I tell GMF to store tags instead of attributes in
the domain model file?
 
</blockquote>
Extended metadata annotations can be used to direct the serialization
style, but it should always be possible to read in what was written out
assuming the same configured implementations are used in each case.
 
</blockquote>
 
I assumed/hoped  - but then it's even stranger ... ? Hmm..
 
</blockquote>
Maybe you've just hit a case I've not seen before.  Not sure how you
ended up with this model.  Did it start as a schema? The default value
of "" seems odd for a repeating element... 
<blockquote cite="mid:gfhc9u$ert$1@build.eclipse.org" type="cite"> 
Greetings,
 
 
    Ralf
 
</blockquote>
</body>
</html>

--------------010103020302010808080805--

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211166 is a reply to message #211150]

Thu, 13 November 2008 11:25

Eclipse User

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211174 is a reply to message #211166]

Thu, 13 November 2008 11:45

Eclipse User

Ralf,

Comments below.

Ralf Buschermoehle wrote:
> Hi Ed,
>
> Comments below.
>
> Ed Merks wrote:
>> Ralf,
>>
>> Comments below.
>>
>> Ralf Buschermoehle wrote:
>>> Hi Ed,
>>>
>>> thanks (as always) for the fast reply! Comments below.
>>>
>>> Ed Merks wrote:
>>>> Ralf,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Ralf Buschermoehle wrote:
>>>>> Hello,
>>>>>
>>>>> See <Topic> ... when an element is e.g. moved in the GMF editor,
>>>>> *unsed* properties are stored in the corresponding domain model
>>>>> xml file as attributes even if they have been modeled with upper
>>>>> multiplicities of "-1" in the ecore. They should be stored as
>>>>>
>>>>> <featureX>
>>>>>
>>>>> <featureX/>
>>>>>
>>>>> but they are stored as
>>>>>
>>>>> <... featureX="">
>>>> I'd expect this only if featureX is an unsettable feature.
>>>
>>> Hm, no ... featureX is defined in the ecore as
>>>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>> unique="false"
>>> upperBound="-1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2003/XMLType#//String"
>>> defaultValueLiteral="">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="kind" value="element"/>
>>> <details key="name" value="featureX"/>
>>> </eAnnotations>
>>> </eStructuralFeatures>
>> It really looks to me like XMLSaveImpl.saveManyEmpty is being
>> called. Which happens for unsettable features. Oh and I see, it
>> will happen for things with a default value as well.
>>
>> protected boolean shouldSaveFeature(EObject o,
>> EStructuralFeature f)
>> {
>> return o.eIsSet(f) || keepDefaults && f.getDefaultValueLiteral()
>> != null;
>> }
>>
>> Probably this default value is kind of bogus?
>
> Sounds resonable ... I deleted default value in the ecore ...
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
> unique="false"
> upperBound="-1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="element"/>
> <details key="name" value="FeatureX"/>
> </eAnnotations>
> </eStructuralFeatures>
>
> But unfortunately the error persisted.
Did you try setting a breakpoint in saveManyEmpty? Something is making
it get there...
> Then I tried to remove the EAnnotations because I did not use them in
> my ecore models (that work fine). And viola the error is gone ...
Because then it doesn't insist it must be an element such that an
attribute is invalid.
> Unfortunately I cannot exactly reproduce if it's only one
> detail/both/or all eAnnotations of the elements. At least the last
> case works ...
It would be good to understand why it's saving this way. You can see it
ought to do that only if the feature is considered set or you're keeping
defaults and their is a default...
>
> Hm, I don't know (see later comments) why they use a featureX and
> write it with an uppercase letter (FeatureX) in the XML file ... ?
> Well,...
>
>>>> In that case, the feature can be considered set even if the list is
>>>> empty, and what you show above is how this "set empty list" is
>>>> represented in XMI. It can't be represented at all in an XML
>>>> (non-XMI) serialization.
>>>
>>> Yes, if I delete the attributes everything is fine (or set value(s)).
>>>
>>>>>
>>>>> Then the generated EMF editor says ...
>>>>>
>>>>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>>>>> 'FeatureX' not found."
>>>>>
>>>>> .... when I try to open the domain file.
>>>> Are you using the same resource implementation with the same
>>>> options in each case?
>>>
>>> Yes. If you are interested I can send you the model files
>>> (emf/gmf/example)?
>>>
>>>>> It is totally correct stored inside tags when I *set* the values
>>>>> in the GMF editor.
>>>>>
>>>>> 1.) Why are features stored at all when I did not set them?
>>>>>
>>>>> 1.a.) Can this be avoided (the storage) and how?
>>>>>
>>>>> 2.) If not (1.a.) can I tell GMF to store tags instead of
>>>>> attributes in the domain model file?
>>>> Extended metadata annotations can be used to direct the
>>>> serialization style, but it should always be possible to read in
>>>> what was written out assuming the same configured implementations
>>>> are used in each case.
>>>
>>> I assumed/hoped - but then it's even stranger ... ? Hmm..
>> Maybe you've just hit a case I've not seen before. Not sure how you
>> ended up with this model. Did it start as a schema? The default
>> value of "" seems odd for a repeating element...
>
> Guess you're right - I use directly the ecore from the EPF project -
> and IMHO I also found some schema files when I browsed through their
> project.
What did this schema look like? Maybe I'm doing something not so good
in the XSD to Ecore Mapping...
>
> Greetings,
>
> Ralf

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211270 is a reply to message #211174]

Fri, 14 November 2008 07:44

Eclipse User

Originally posted by: ralf.buschermoehle.informatik.uni-oldenburg.de

Hi Ed,

Comments below.

Ed Merks wrote:
> Ralf,
>
> Comments below.
>
> Ralf Buschermoehle wrote:
>> Hi Ed,
>>
>> Comments below.
>>
>> Ed Merks wrote:
>>> Ralf,
>>>
>>> Comments below.
>>>
>>> Ralf Buschermoehle wrote:
>>>> Hi Ed,
>>>>
>>>> thanks (as always) for the fast reply! Comments below.
>>>>
>>>> Ed Merks wrote:
>>>>> Ralf,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Ralf Buschermoehle wrote:
>>>>>> Hello,
>>>>>>
>>>>>> See <Topic> ... when an element is e.g. moved in the GMF editor,
>>>>>> *unsed* properties are stored in the corresponding domain model
>>>>>> xml file as attributes even if they have been modeled with upper
>>>>>> multiplicities of "-1" in the ecore. They should be stored as
>>>>>>
>>>>>> <featureX>
>>>>>>
>>>>>> <featureX/>
>>>>>>
>>>>>> but they are stored as
>>>>>>
>>>>>> <... featureX="">
>>>>> I'd expect this only if featureX is an unsettable feature.
>>>>
>>>> Hm, no ... featureX is defined in the ecore as
>>>>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>>> unique="false"
>>>> upperBound="-1" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2003/XMLType#//String"
>>>> defaultValueLiteral="">
>>>> <eAnnotations
>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>> <details key="kind" value="element"/>
>>>> <details key="name" value="featureX"/>
>>>> </eAnnotations>
>>>> </eStructuralFeatures>
>>> It really looks to me like XMLSaveImpl.saveManyEmpty is being
>>> called. Which happens for unsettable features. Oh and I see, it
>>> will happen for things with a default value as well.
>>>
>>> protected boolean shouldSaveFeature(EObject o,
>>> EStructuralFeature f)
>>> {
>>> return o.eIsSet(f) || keepDefaults && f.getDefaultValueLiteral()
>>> != null;
>>> }
>>>
>>> Probably this default value is kind of bogus?
>>
>> Sounds resonable ... I deleted default value in the ecore ...
>>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>> unique="false"
>> upperBound="-1" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2003/XMLType#//String">
>> <eAnnotations
>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>> <details key="kind" value="element"/>
>> <details key="name" value="FeatureX"/>
>> </eAnnotations>
>> </eStructuralFeatures>
>>
>> But unfortunately the error persisted.
> Did you try setting a breakpoint in saveManyEmpty? Something is making
> it get there...

Yes, and according to the implementation (and my understanding) this is
correct ... (meaning it should invoke saveManyEmpty)? The feature value
is set (because of the default value), so sIsSet(f) == true implying the
invocation.

>> Then I tried to remove the EAnnotations because I did not use them in
>> my ecore models (that work fine). And viola the error is gone ...
> Because then it doesn't insist it must be an element such that an
> attribute is invalid.
>> Unfortunately I cannot exactly reproduce if it's only one
>> detail/both/or all eAnnotations of the elements. At least the last
>> case works ...
> It would be good to understand why it's saving this way. You can see it
> ought to do that only if the feature is considered set or you're keeping
> defaults and their is a default...

It seams that "toDOM" == false in ...

if (!toDOM)
{
saveManyEmpty(f);
}
else
{
helper.populateNameInfo(nameInfo, f);
Attr attr =
document.createAttributeNS(nameInfo.getNamespaceURI(),
nameInfo.getQualifiedName());
((Element)currentNode).setAttributeNodeNS(attr);
handler.recordValues(attr, o, f, null);
}

But why? toDOM is initially (XMLSaveImpl) set to true. Where set to false?

>>
>> Hm, I don't know (see later comments) why they use a featureX and
>> write it with an uppercase letter (FeatureX) in the XML file ... ?
>> Well,...
>>
>>>>> In that case, the feature can be considered set even if the list is
>>>>> empty, and what you show above is how this "set empty list" is
>>>>> represented in XMI. It can't be represented at all in an XML
>>>>> (non-XMI) serialization.
>>>>
>>>> Yes, if I delete the attributes everything is fine (or set value(s)).
>>>>
>>>>>>
>>>>>> Then the generated EMF editor says ...
>>>>>>
>>>>>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>>>>>> 'FeatureX' not found."
>>>>>>
>>>>>> .... when I try to open the domain file.
>>>>> Are you using the same resource implementation with the same
>>>>> options in each case?
>>>>
>>>> Yes. If you are interested I can send you the model files
>>>> (emf/gmf/example)?
>>>>
>>>>>> It is totally correct stored inside tags when I *set* the values
>>>>>> in the GMF editor.
>>>>>>
>>>>>> 1.) Why are features stored at all when I did not set them?
>>>>>>
>>>>>> 1.a.) Can this be avoided (the storage) and how?
>>>>>>
>>>>>> 2.) If not (1.a.) can I tell GMF to store tags instead of
>>>>>> attributes in the domain model file?
>>>>> Extended metadata annotations can be used to direct the
>>>>> serialization style, but it should always be possible to read in
>>>>> what was written out assuming the same configured implementations
>>>>> are used in each case.
>>>>
>>>> I assumed/hoped - but then it's even stranger ... ? Hmm..
>>> Maybe you've just hit a case I've not seen before. Not sure how you
>>> ended up with this model. Did it start as a schema? The default
>>> value of "" seems odd for a repeating element...
>>
>> Guess you're right - I use directly the ecore from the EPF project -
>> and IMHO I also found some schema files when I browsed through their
>> project.
> What did this schema look like? Maybe I'm doing something not so good
> in the XSD to Ecore Mapping...

You can find the files in the epf project sources.

cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.ecore

cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.xsd

Unfortunately a simple full text search "fulfilled" (which is
"featureX") in DescribableElement failed in the XSD file - but I have no
Idea if/how they used the schema file in the project.

Greetings,

Ralf

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211281 is a reply to message #211270]

Fri, 14 November 2008 07:55

Eclipse User

Originally posted by: ralf.buschermoehle.informatik.uni-oldenburg.de

Appendix added ...

Ralf Buschermoehle wrote:
> Hi Ed,
>
> Comments below.
>
> Ed Merks wrote:
>> Ralf,
>>
>> Comments below.
>>
>> Ralf Buschermoehle wrote:
>>> Hi Ed,
>>>
>>> Comments below.
>>>
>>> Ed Merks wrote:
>>>> Ralf,
>>>>
>>>> Comments below.
>>>>
>>>> Ralf Buschermoehle wrote:
>>>>> Hi Ed,
>>>>>
>>>>> thanks (as always) for the fast reply! Comments below.
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Ralf,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> Ralf Buschermoehle wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> See <Topic> ... when an element is e.g. moved in the GMF editor,
>>>>>>> *unsed* properties are stored in the corresponding domain model
>>>>>>> xml file as attributes even if they have been modeled with upper
>>>>>>> multiplicities of "-1" in the ecore. They should be stored as
>>>>>>>
>>>>>>> <featureX>
>>>>>>>
>>>>>>> <featureX/>
>>>>>>>
>>>>>>> but they are stored as
>>>>>>>
>>>>>>> <... featureX="">
>>>>>> I'd expect this only if featureX is an unsettable feature.
>>>>>
>>>>> Hm, no ... featureX is defined in the ecore as
>>>>>
>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>>>> unique="false"
>>>>> upperBound="-1" eType="ecore:EDataType
>>>>> http://www.eclipse.org/emf/2003/XMLType#//String"
>>>>> defaultValueLiteral="">
>>>>> <eAnnotations
>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>> <details key="kind" value="element"/>
>>>>> <details key="name" value="featureX"/>
>>>>> </eAnnotations>
>>>>> </eStructuralFeatures>
>>>> It really looks to me like XMLSaveImpl.saveManyEmpty is being
>>>> called. Which happens for unsettable features. Oh and I see, it
>>>> will happen for things with a default value as well.
>>>>
>>>> protected boolean shouldSaveFeature(EObject o,
>>>> EStructuralFeature f)
>>>> {
>>>> return o.eIsSet(f) || keepDefaults &&
>>>> f.getDefaultValueLiteral()
>>>> != null;
>>>> }
>>>>
>>>> Probably this default value is kind of bogus?
>>>
>>> Sounds resonable ... I deleted default value in the ecore ...
>>>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>> unique="false"
>>> upperBound="-1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2003/XMLType#//String">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="kind" value="element"/>
>>> <details key="name" value="FeatureX"/>
>>> </eAnnotations>
>>> </eStructuralFeatures>
>>>
>>> But unfortunately the error persisted.
>> Did you try setting a breakpoint in saveManyEmpty? Something is
>> making it get there...
>
> Yes, and according to the implementation (and my understanding) this is
> correct ... (meaning it should invoke saveManyEmpty)? The feature value
> is set (because of the default value), so sIsSet(f) == true implying the
> invocation.
>
>>> Then I tried to remove the EAnnotations because I did not use them in
>>> my ecore models (that work fine). And viola the error is gone ...
>> Because then it doesn't insist it must be an element such that an
>> attribute is invalid.
>>> Unfortunately I cannot exactly reproduce if it's only one
>>> detail/both/or all eAnnotations of the elements. At least the last
>>> case works ...
>> It would be good to understand why it's saving this way. You can see
>> it ought to do that only if the feature is considered set or you're
>> keeping defaults and their is a default...
>
> It seams that "toDOM" == false in ...
>
> if (!toDOM)
> {
> saveManyEmpty(f);
> }
> else
> {
> helper.populateNameInfo(nameInfo, f);
> Attr attr = document.createAttributeNS(nameInfo.getNamespaceURI(),
> nameInfo.getQualifiedName());
> ((Element)currentNode).setAttributeNodeNS(attr);
> handler.recordValues(attr, o, f, null);
> }
>
> But why? toDOM is initially (XMLSaveImpl) set to true. Where set to false?

Initially is not correct ... I found only one assignment for toDOM

public Document save(XMLResource resource, Document doc, Map<?, ?>
options, DOMHandler handler)
{
toDOM = true;

and thought this would be called - but it is not ... ?

>
>>>
>>> Hm, I don't know (see later comments) why they use a featureX and
>>> write it with an uppercase letter (FeatureX) in the XML file ... ?
>>> Well,...
>>>
>>>>>> In that case, the feature can be considered set even if the list
>>>>>> is empty, and what you show above is how this "set empty list" is
>>>>>> represented in XMI. It can't be represented at all in an XML
>>>>>> (non-XMI) serialization.
>>>>>
>>>>> Yes, if I delete the attributes everything is fine (or set value(s)).
>>>>>
>>>>>>>
>>>>>>> Then the generated EMF editor says ...
>>>>>>>
>>>>>>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>>>>>>> 'FeatureX' not found."
>>>>>>>
>>>>>>> .... when I try to open the domain file.
>>>>>> Are you using the same resource implementation with the same
>>>>>> options in each case?
>>>>>
>>>>> Yes. If you are interested I can send you the model files
>>>>> (emf/gmf/example)?
>>>>>
>>>>>>> It is totally correct stored inside tags when I *set* the values
>>>>>>> in the GMF editor.
>>>>>>>
>>>>>>> 1.) Why are features stored at all when I did not set them?
>>>>>>>
>>>>>>> 1.a.) Can this be avoided (the storage) and how?
>>>>>>>
>>>>>>> 2.) If not (1.a.) can I tell GMF to store tags instead of
>>>>>>> attributes in the domain model file?
>>>>>> Extended metadata annotations can be used to direct the
>>>>>> serialization style, but it should always be possible to read in
>>>>>> what was written out assuming the same configured implementations
>>>>>> are used in each case.
>>>>>
>>>>> I assumed/hoped - but then it's even stranger ... ? Hmm..
>>>> Maybe you've just hit a case I've not seen before. Not sure how you
>>>> ended up with this model. Did it start as a schema? The default
>>>> value of "" seems odd for a repeating element...
>>>
>>> Guess you're right - I use directly the ecore from the EPF project -
>>> and IMHO I also found some schema files when I browsed through their
>>> project.
>> What did this schema look like? Maybe I'm doing something not so good
>> in the XSD to Ecore Mapping...
>
> You can find the files in the epf project sources.
>
> cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.ecore
>
> cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.xsd
>
>
> Unfortunately a simple full text search "fulfilled" (which is
> "featureX") in DescribableElement failed in the XSD file - but I have no
> Idea if/how they used the schema file in the project.
>
> Greetings,
>
> Ralf

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211288 is a reply to message #211281]

Fri, 14 November 2008 08:52

Eclipse User

Ralf,

The toDOM thing is a red herring. That's just whether we're creating a
org.w3c.dom.Document instance (much slower) or using an XMLString (fast
and small)...

Ralf Buschermoehle wrote:
> Appendix added ...
>
> Ralf Buschermoehle wrote:
>> Hi Ed,
>>
>> Comments below.
>>
>> Ed Merks wrote:
>>> Ralf,
>>>
>>> Comments below.
>>>
>>> Ralf Buschermoehle wrote:
>>>> Hi Ed,
>>>>
>>>> Comments below.
>>>>
>>>> Ed Merks wrote:
>>>>> Ralf,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Ralf Buschermoehle wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> thanks (as always) for the fast reply! Comments below.
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Ralf,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>>
>>>>>>> Ralf Buschermoehle wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> See <Topic> ... when an element is e.g. moved in the GMF
>>>>>>>> editor, *unsed* properties are stored in the corresponding
>>>>>>>> domain model xml file as attributes even if they have been
>>>>>>>> modeled with upper multiplicities of "-1" in the ecore. They
>>>>>>>> should be stored as
>>>>>>>>
>>>>>>>> <featureX>
>>>>>>>>
>>>>>>>> <featureX/>
>>>>>>>>
>>>>>>>> but they are stored as
>>>>>>>>
>>>>>>>> <... featureX="">
>>>>>>> I'd expect this only if featureX is an unsettable feature.
>>>>>>
>>>>>> Hm, no ... featureX is defined in the ecore as
>>>>>>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>>>>> unique="false"
>>>>>> upperBound="-1" eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2003/XMLType#//String"
>>>>>> defaultValueLiteral="">
>>>>>> <eAnnotations
>>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>>> <details key="kind" value="element"/>
>>>>>> <details key="name" value="featureX"/>
>>>>>> </eAnnotations>
>>>>>> </eStructuralFeatures>
>>>>> It really looks to me like XMLSaveImpl.saveManyEmpty is being
>>>>> called. Which happens for unsettable features. Oh and I see, it
>>>>> will happen for things with a default value as well.
>>>>>
>>>>> protected boolean shouldSaveFeature(EObject o,
>>>>> EStructuralFeature f)
>>>>> {
>>>>> return o.eIsSet(f) || keepDefaults &&
>>>>> f.getDefaultValueLiteral()
>>>>> != null;
>>>>> }
>>>>>
>>>>> Probably this default value is kind of bogus?
>>>>
>>>> Sounds resonable ... I deleted default value in the ecore ...
>>>>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>>> unique="false"
>>>> upperBound="-1" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2003/XMLType#//String">
>>>> <eAnnotations
>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>> <details key="kind" value="element"/>
>>>> <details key="name" value="FeatureX"/>
>>>> </eAnnotations>
>>>> </eStructuralFeatures>
>>>>
>>>> But unfortunately the error persisted.
>>> Did you try setting a breakpoint in saveManyEmpty? Something is
>>> making it get there...
>>
>> Yes, and according to the implementation (and my understanding) this
>> is correct ... (meaning it should invoke saveManyEmpty)? The feature
>> value is set (because of the default value), so sIsSet(f) == true
>> implying the invocation.
>>
>>>> Then I tried to remove the EAnnotations because I did not use them
>>>> in my ecore models (that work fine). And viola the error is gone ...
>>> Because then it doesn't insist it must be an element such that an
>>> attribute is invalid.
>>>> Unfortunately I cannot exactly reproduce if it's only one
>>>> detail/both/or all eAnnotations of the elements. At least the last
>>>> case works ...
>>> It would be good to understand why it's saving this way. You can
>>> see it ought to do that only if the feature is considered set or
>>> you're keeping defaults and their is a default...
>>
>> It seams that "toDOM" == false in ...
>>
>> if (!toDOM)
>> {
>> saveManyEmpty(f);
>> }
>> else
>> {
>> helper.populateNameInfo(nameInfo, f);
>> Attr attr =
>> document.createAttributeNS(nameInfo.getNamespaceURI(),
>> nameInfo.getQualifiedName());
>> ((Element)currentNode).setAttributeNodeNS(attr);
>> handler.recordValues(attr, o, f, null);
>> }
>>
>> But why? toDOM is initially (XMLSaveImpl) set to true. Where set to
>> false?
>
> Initially is not correct ... I found only one assignment for toDOM
>
> public Document save(XMLResource resource, Document doc, Map<?, ?>
> options, DOMHandler handler)
> {
> toDOM = true;
>
> and thought this would be called - but it is not ... ?
>
>>
>>>>
>>>> Hm, I don't know (see later comments) why they use a featureX and
>>>> write it with an uppercase letter (FeatureX) in the XML file ... ?
>>>> Well,...
>>>>
>>>>>>> In that case, the feature can be considered set even if the list
>>>>>>> is empty, and what you show above is how this "set empty list"
>>>>>>> is represented in XMI. It can't be represented at all in an XML
>>>>>>> (non-XMI) serialization.
>>>>>>
>>>>>> Yes, if I delete the attributes everything is fine (or set
>>>>>> value(s)).
>>>>>>
>>>>>>>>
>>>>>>>> Then the generated EMF editor says ...
>>>>>>>>
>>>>>>>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>>>>>>>> 'FeatureX' not found."
>>>>>>>>
>>>>>>>> .... when I try to open the domain file.
>>>>>>> Are you using the same resource implementation with the same
>>>>>>> options in each case?
>>>>>>
>>>>>> Yes. If you are interested I can send you the model files
>>>>>> (emf/gmf/example)?
>>>>>>
>>>>>>>> It is totally correct stored inside tags when I *set* the
>>>>>>>> values in the GMF editor.
>>>>>>>>
>>>>>>>> 1.) Why are features stored at all when I did not set them?
>>>>>>>>
>>>>>>>> 1.a.) Can this be avoided (the storage) and how?
>>>>>>>>
>>>>>>>> 2.) If not (1.a.) can I tell GMF to store tags instead of
>>>>>>>> attributes in the domain model file?
>>>>>>> Extended metadata annotations can be used to direct the
>>>>>>> serialization style, but it should always be possible to read in
>>>>>>> what was written out assuming the same configured
>>>>>>> implementations are used in each case.
>>>>>>
>>>>>> I assumed/hoped - but then it's even stranger ... ? Hmm..
>>>>> Maybe you've just hit a case I've not seen before. Not sure how
>>>>> you ended up with this model. Did it start as a schema? The
>>>>> default value of "" seems odd for a repeating element...
>>>>
>>>> Guess you're right - I use directly the ecore from the EPF project
>>>> - and IMHO I also found some schema files when I browsed through
>>>> their project.
>>> What did this schema look like? Maybe I'm doing something not so
>>> good in the XSD to Ecore Mapping...
>>
>> You can find the files in the epf project sources.
>>
>> cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.ecore
>>
>> cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.xsd
>>
>>
>> Unfortunately a simple full text search "fulfilled" (which is
>> "featureX") in DescribableElement failed in the XSD file - but I have
>> no Idea if/how they used the schema file in the project.
>>
>> Greetings,
>>
>> Ralf

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211295 is a reply to message #211174]

Fri, 14 November 2008 08:54

Eclipse User

Originally posted by: ralf.buschermoehle.informatik.uni-oldenburg.de

Hi Ed,

if the defaultValue is empty, then shouldSaveFeature(o, f) calls
o.sIsSet(f) which is a CDO (1.0.3) Implementation (CDOObjectImpl)

@Override
public boolean eIsSet(EStructuralFeature feature)
{
if (FSMUtil.isTransient(this)) // == true
{
// TODO What about defaultValues != null?
if (eSettings == null) // == false
{
return false;
}

return eSettings[eDynamicFeatureID(feature)] != null; // returned
}

// Delegate to CDOStore
return super.eIsSet(feature);
}

eSettings[eDynamicFeatureID(feature)] is not "null". As far as I
understand the variable space of the debug run it should check if the
value (called data?) of the feature is set and not if there exists a
feature? Well, seems not to be EMF related.

Greetings,

Ralf

P.S. The "error" persists in CDO 2.0.v200811031537.

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211302 is a reply to message #211270]

Fri, 14 November 2008 08:54

Eclipse User

Ralf,

Comments below.

Ralf Buschermoehle wrote:
> Hi Ed,
>
> Comments below.
>
> Ed Merks wrote:
>> Ralf,
>>
>> Comments below.
>>
>> Ralf Buschermoehle wrote:
>>> Hi Ed,
>>>
>>> Comments below.
>>>
>>> Ed Merks wrote:
>>>> Ralf,
>>>>
>>>> Comments below.
>>>>
>>>> Ralf Buschermoehle wrote:
>>>>> Hi Ed,
>>>>>
>>>>> thanks (as always) for the fast reply! Comments below.
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Ralf,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> Ralf Buschermoehle wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> See <Topic> ... when an element is e.g. moved in the GMF editor,
>>>>>>> *unsed* properties are stored in the corresponding domain model
>>>>>>> xml file as attributes even if they have been modeled with upper
>>>>>>> multiplicities of "-1" in the ecore. They should be stored as
>>>>>>>
>>>>>>> <featureX>
>>>>>>>
>>>>>>> <featureX/>
>>>>>>>
>>>>>>> but they are stored as
>>>>>>>
>>>>>>> <... featureX="">
>>>>>> I'd expect this only if featureX is an unsettable feature.
>>>>>
>>>>> Hm, no ... featureX is defined in the ecore as
>>>>>
>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>>>> unique="false"
>>>>> upperBound="-1" eType="ecore:EDataType
>>>>> http://www.eclipse.org/emf/2003/XMLType#//String"
>>>>> defaultValueLiteral="">
>>>>> <eAnnotations
>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>> <details key="kind" value="element"/>
>>>>> <details key="name" value="featureX"/>
>>>>> </eAnnotations>
>>>>> </eStructuralFeatures>
>>>> It really looks to me like XMLSaveImpl.saveManyEmpty is being
>>>> called. Which happens for unsettable features. Oh and I see, it
>>>> will happen for things with a default value as well.
>>>>
>>>> protected boolean shouldSaveFeature(EObject o,
>>>> EStructuralFeature f)
>>>> {
>>>> return o.eIsSet(f) || keepDefaults &&
>>>> f.getDefaultValueLiteral()
>>>> != null;
>>>> }
>>>>
>>>> Probably this default value is kind of bogus?
>>>
>>> Sounds resonable ... I deleted default value in the ecore ...
>>>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="featureX"
>>> unique="false"
>>> upperBound="-1" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2003/XMLType#//String">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="kind" value="element"/>
>>> <details key="name" value="FeatureX"/>
>>> </eAnnotations>
>>> </eStructuralFeatures>
>>>
>>> But unfortunately the error persisted.
>> Did you try setting a breakpoint in saveManyEmpty? Something is
>> making it get there...
>
> Yes, and according to the implementation (and my understanding) this
> is correct ... (meaning it should invoke saveManyEmpty)? The feature
> value is set (because of the default value), so sIsSet(f) == true
> implying the invocation.
You said you got rid of the default value though. So what's making the
empty list be set?
>
>>> Then I tried to remove the EAnnotations because I did not use them
>>> in my ecore models (that work fine). And viola the error is gone ...
>> Because then it doesn't insist it must be an element such that an
>> attribute is invalid.
>>> Unfortunately I cannot exactly reproduce if it's only one
>>> detail/both/or all eAnnotations of the elements. At least the last
>>> case works ...
>> It would be good to understand why it's saving this way. You can see
>> it ought to do that only if the feature is considered set or you're
>> keeping defaults and their is a default...
>
> It seams that "toDOM" == false in ...
>
> if (!toDOM)
> {
> saveManyEmpty(f);
> }
> else
> {
> helper.populateNameInfo(nameInfo, f);
> Attr attr =
> document.createAttributeNS(nameInfo.getNamespaceURI(),
> nameInfo.getQualifiedName());
> ((Element)currentNode).setAttributeNodeNS(attr);
> handler.recordValues(attr, o, f, null);
> }
>
> But why? toDOM is initially (XMLSaveImpl) set to true. Where set to
> false?
>
>>>
>>> Hm, I don't know (see later comments) why they use a featureX and
>>> write it with an uppercase letter (FeatureX) in the XML file ... ?
>>> Well,...
>>>
>>>>>> In that case, the feature can be considered set even if the list
>>>>>> is empty, and what you show above is how this "set empty list" is
>>>>>> represented in XMI. It can't be represented at all in an XML
>>>>>> (non-XMI) serialization.
>>>>>
>>>>> Yes, if I delete the attributes everything is fine (or set value(s)).
>>>>>
>>>>>>>
>>>>>>> Then the generated EMF editor says ...
>>>>>>>
>>>>>>> "org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
>>>>>>> 'FeatureX' not found."
>>>>>>>
>>>>>>> .... when I try to open the domain file.
>>>>>> Are you using the same resource implementation with the same
>>>>>> options in each case?
>>>>>
>>>>> Yes. If you are interested I can send you the model files
>>>>> (emf/gmf/example)?
>>>>>
>>>>>>> It is totally correct stored inside tags when I *set* the values
>>>>>>> in the GMF editor.
>>>>>>>
>>>>>>> 1.) Why are features stored at all when I did not set them?
>>>>>>>
>>>>>>> 1.a.) Can this be avoided (the storage) and how?
>>>>>>>
>>>>>>> 2.) If not (1.a.) can I tell GMF to store tags instead of
>>>>>>> attributes in the domain model file?
>>>>>> Extended metadata annotations can be used to direct the
>>>>>> serialization style, but it should always be possible to read in
>>>>>> what was written out assuming the same configured implementations
>>>>>> are used in each case.
>>>>>
>>>>> I assumed/hoped - but then it's even stranger ... ? Hmm..
>>>> Maybe you've just hit a case I've not seen before. Not sure how
>>>> you ended up with this model. Did it start as a schema? The
>>>> default value of "" seems odd for a repeating element...
>>>
>>> Guess you're right - I use directly the ecore from the EPF project -
>>> and IMHO I also found some schema files when I browsed through their
>>> project.
>> What did this schema look like? Maybe I'm doing something not so
>> good in the XSD to Ecore Mapping...
>
> You can find the files in the epf project sources.
>
> cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.ecore
>
> cvs://dev.eclipse.org/cvsroot/technology/org.eclipse.epf/com poser/1.5/plugins/org.eclipse.xml.uma/src/model/UMA.xsd
>
>
> Unfortunately a simple full text search "fulfilled" (which is
> "featureX") in DescribableElement failed in the XSD file - but I have
> no Idea if/how they used the schema file in the project.
I might have time to look at it later, but I need to travel this weekend
so have lots to prepare...
>
> Greetings,
>
> Ralf

Re: Feature or Bug? Empty properties with multiplicities of n are created as attribute in the corres [message #211311 is a reply to message #211295]

Fri, 14 November 2008 09:03

Eclipse User

Ralph,

That looks bad to me it probably should be delegating to this method.

protected boolean eDynamicIsSet(int dynamicFeatureID,
EStructuralFeature eFeature)
{
return
dynamicFeatureID < 0 ?
eOpenIsSet(eFeature) :
eSettingDelegate(eFeature).dynamicIsSet(this, eSettings(),
dynamicFeatureID);
}

Eike tells me this is fixed in 2.0...

Ralf Buschermoehle wrote:
> Hi Ed,
>
> if the defaultValue is empty, then shouldSaveFeature(o, f) calls
> o.sIsSet(f) which is a CDO (1.0.3) Implementation (CDOObjectImpl)
>
> @Override
> public boolean eIsSet(EStructuralFeature feature)
> {
> if (FSMUtil.isTransient(this)) // == true
> {
> // TODO What about defaultValues != null?
> if (eSettings == null) // == false
> {
> return false;
> }
>
> return eSettings[eDynamicFeatureID(feature)] != null; // returned
> }
>
> // Delegate to CDOStore
> return super.eIsSet(feature);
> }
>
> eSettings[eDynamicFeatureID(feature)] is not "null". As far as I
> understand the variable space of the debug run it should check if the
> value (called data?) of the feature is set and not if there exists a
> feature? Well, seems not to be EMF related.
>
> Greetings,
>
> Ralf
>
> P.S. The "error" persists in CDO 2.0.v200811031537.

Previous Topic:	CreationWizard could not be started
Next Topic:	button look'n feel like in rcp

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jun 07 09:19:09 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter