Issue 17419: At the Parameter element, initial values for Array or Aggregates may not be set. (xtce-rtf)
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity: 
Summary: At the Parameter element, initial values for Array or Aggregates may not be set.   (It actually says this in the annotation.)

Possible answers:

4) Since Parameter's @initialValue is a string, I don't see why comma delimited and {}  initializers can't be used similar to C, C++, Java, etc... these things should be pretty easy to parse.   Of course some extra checking will be needed to make sure the list of items fits into the data type and perhaps there's some sticky cases to be considered which would all need to written up and documented which is probably why the annotation says its not supported in the first place.


Resolution: 
Revised Text: 
Actions taken:
June 11, 2012: received issue
Discussion: 

End of Annotations:=====

m: "Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY
 SOLUTIONS]" <james.k.rice-1@nasa.gov>
To: Juergen Boldt <juergen@omg.org>,
        "Overeem, David T"
        <david.t.overeem@boeing.com>,
        "space@omg.org" <space@omg.org>
Date: Mon, 11 Jun 2012 11:48:10 -0500
Subject: RE: Using AggregateParameterTypes
Thread-Topic: Using AggregateParameterTypes
Thread-Index: Ac1Hy0ng/oON6EaKSlW7d0lrL6ykoAAIeVNT
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000
 definitions=2012-06-11_04:2012-06-11,2012-06-11,1970-01-01 signatures=0
X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id q5BGmMxD011705


These issues might have been previously captured already but they are:

4) At the Parameter element, initial values for Array or Aggregates may not be set.   (It actually says this in the annotation.)


4) Since Parameter's @initialValue is a string, I don't see why comma delimited and {}  initializers can't be used similar to C, C++, Java, etc... these things should be pretty easy to parse.   Of course some extra checking will be needed to make sure the list of items fits into the data type and perhaps there's some sticky cases to be considered which would all need to written up and documented which is probably why the annotation says its not supported in the first place.



________________________________________
From: Juergen Boldt [juergen@omg.org]
Sent: Monday, June 11, 2012 8:09 AM
To: Overeem, David T; space@omg.org
Subject: Re: Using AggregateParameterTypes


should I file as an issue?



-Juergen



At 10:45 AM 6/9/2012, Overeem, David T wrote:
Hi again folks.  I ran into another interesting issue when using the TelemetryMetaData/AggregateParameterType element and trying to apply the shortDescription to my structure attributes.  See fragment example below:


A structure type:


<AggregateParameterType name="MYSTRUCTURENAME_TMType">
                <MemberList>
                                <Member typeRef=" MYSTRUCTURENAME �ATTRIBUTE1_TMType" name="ATTRIBUTE1"/>
                                <Member typeRef=" MYSTRUCTURENAME �ATTRIBUTE2_TMType" name="ATTRIBUTE2"/>
                </MemberList>
</AggregateParameterType>


Since I have already aligned the attributes in the type, it seems that in the later ParameterSet, I should define only the structure itself:


<Parameter name="MYSTRUCTURENAME" parameterTypeRef="MYSTRUCTURENAME_TMType" shortDescription="Contains the foo states or something">
                <ParameterProperties dataSource="telemetered" readOnly="true"/>
</Parameter>


In this approach, I have now lost the ability to create a shortDescription for each of the structure members.  I realize that shortDescription can be placed in the individual *ParameterType elements for each attribute and this may need to be the answer.  Some have expressed a preference for using shortDescription within the Parameter element instead.  I might propose that we clarify this � or perhaps add shortDescription and initialValue to MemberList/Member to compensate for not having a Parameter element for each of the structure attributes.  Another possible approach exists where one could define it �C� style and specify <Parameter name=�MYSTRUCTURENAME.ATTRIBUTE1� for the attributes, however the period is not allowable in the name.  Yet another approach has been suggested by Harris to use the SystemName element within the Parameter element.  In that approach, I appear (correct me if I am out of whack) to lose the separate namespace that a C structure would otherwise provide.


Another minor note � it seems like the typeRef in the Member element might be better name parameterTypeRef to be consistent with other locations where ParameterTypes are referenced?


Thoughts anyone?  I am sure I did not summarize this as good as I could have.