[Ccsds-omg-liaison] RE: Using AggregateParameterTypes

Mon Jun 11 12:48:10 EDT 2012

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

1) There's no short description or long description at the Member element of AggregateParameterType or AggregateArgumentType

2) AggregateParameterType or AggregateArgumentType Member attribute 'typeRef' is vague in that it does not specify whether one is referring to a ParameterType or ArgumentType. 

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

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

Possible answers:

1)  Use the short/long descriptions of the referred to types.  Alternatively we'd have to re-construct the schema type add descriptive info.

2) It's safe to assume that the AggregateParameterType member should only refer to ParameterTypes and AggregateArgumentType members should only refer to ArgumentType.  Alternatively again, the schema types could be split along the parameter and argument lines... and differentiated explicitly.

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.

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 at omg.org]
Sent: Monday, June 11, 2012 8:09 AM
To: Overeem, David T; space at 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.

Juergen Boldt
Director, Member Services
140 Kendrick Street, Building A Suite 300
Needham, MA 02494 USA

Tel:  781 444 0404 x 132
fax:  781 444 0320

www.omg.org

<http://www.omg.org/>[http://www.omg.org/images/signature-2.gif] <http://www.omg.org/signature.htm>