Issue 17418: Member of an AggregateParameterType or AggregateArgumentType can't be an ArrayParameterType or ArrayArgumentType (xtce-rtf)
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Uncategorized Issue
Severity: 
Summary: 3) A Member of an AggregateParameterType or AggregateArgumentType cannot be an ArrayParameterType or ArrayArgumentType

Possible answers:

3) This one typically comes up when source material has adopted the C syntax for specifying strings as char arrays and its being used in a 'struct'.   In XTCE do not map char arrays that are strings to an 8-bit StringParameterType and then an ArrayParameterType that refers to it.   Instead calculate the length from the char array and make a StringParameterType that long to hold it and refer to that in the Member element.   To date even though this works (largely), it does not produce a happy face for the folks that have the original syntax.  The alternative is a complete re-working of XTCE's array description


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:

3) A Member of an AggregateParameterType or AggregateArgumentType cannot be an ArrayParameterType or ArrayArgumentType

3) This one typically comes up when source material has adopted the C syntax for specifying strings as char arrays and its being used in a 'struct'.   In XTCE do not map char arrays that are strings to an 8-bit StringParameterType and then an ArrayParameterType that refers to it.   Instead calculate the length from the char array and make a StringParameterType that long to hold it and refer to that in the Member element.   To date even though this works (largely), it does not produce a happy face for the folks that have the original syntax.  The alternative is a complete re-working of XTCE's array description


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.