[Ccsds-omg-liaison] RE: Using AggregateParameterTypes

[Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]]

All you can do is use the short description in the type for each member -- but yes there's no way to make a localized short description for each Member directly.   This may be fine unless you are re-using a parameter type... which is another reason I've found it easier in most software based translation applications to simply make a new type for each parameter or in this case for each member... 

I would not use the SystemName to hold descriptive information unless it's a system name.   

I would say a general rule of thumb is to not misuse an XTCE element that has a clear intent on what it means if at all possible... 

As for initial value, each parameter type has an initialValue and this can be used for the purpose -- the parameter initial value simply overshadows the type initial value anyway.   However again, this may work best for you if the type is always associated 1 to 1 with a parameter, argument or in this case member  (same would be true for array types).

There's another issue that's come up over and over again with XTCE Aggregate -- it cannot have an array member.   The reason is that the array's dimensions are specified in the container in the array entry, and there's no way to say that an aggregate parameter that has a member array type has a dimensions of size 2 by 2" for example.

As for the "typeRef" -- it's the more generic term there because its part of the AggregateDataType schema type.   And this is re-used down in the AggregateArgumentType area...  I think you'll find many of the schema types are re-used throughout the various areas of the schemas, sometimes this is good but in other cases it creates a lack of clarity. 

Personally I'd like to see this all cleaned up but I don't see the support out there for the effort.

Finally in ParameterInstanceRefs -- you should be able to use the "MYSTRUCT.ATTRIBUTE" syntax to get at a member value if needed ... for example in an IncludeCondition or something like that.


 

________________________________________
From: Overeem, David T [david.t.overeem at boeing.com]
Sent: Saturday, June 09, 2012 10:45 AM
To: space at omg.org
Subject: Using AggregateParameterTypes

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.