Issues for Mailing List of the XTCE Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7659: ContainerType issue
Issue 7979: CommandContainer under the MetaCommand
Issue 7980: CommandContainer issue
Issue 7981: initialValue attribute only exists for a ParameterType or ArgumentType
Issue 8057: Package Identification: MessageKeys or Inheritance
Issue 14464: TimeAssociation should be settable at the Container

Issue 7659: ContainerType issue (xtce-ftf)

ContainerType needs optional SizeInBits element to support calculating locations of list entries that use the end of the container (e.g. referenceLocation="containerEnd"). Note that an IntegerValueType element is preferred over an integer attribute since it supports fixed, dynamic and conditional values. 

In the CommandContainer under the MetaCommand, inside the EntryList,
there is a division between groupings of the Parameter/ContainerRefEntries
and the FixedValue/ArgumentRefEntries.  The problem is what this does is
make you have to define ALL your ParameterRefEntries and ContainerRefEntries
BEFORE defining any FixedValues or ArgumentRefs inside a CommandContainer.
For example, the following sequence of entries would be illegal for a
CommandContainer:
FixedValueEntry-ContainerRefEntry-ParameterRefEntry-ArgumentRefEntry.
Unless there is a legitimate reason for the separation, I think the
FixedValueEntry and the ArgumentRefEntry needs to be added to the same
grouping that the ParameterRefEntry/ContainerRefEntry is in. 


You're probably right.  We simply extended the EntryListType to create a
CommandEntryList type.  While this keeps the schema simpler, it does make
the XML documents messier.  We usually opt for better XML over better
Schema.

Another question involving the CommandContainer.  In the CommandMetaData
there are two ways to create a CommandContainer: inside a MetaCommand or
inside the CommandContainerSet.  For some reason the CommandContainer inside
the MetaCommand has an ArgumentRefEntry and a FixedValueEntry but the
CommandContainer inside the CommandContainerSet does not.  The reason they
are different is that the CommandContainer inside the MetaCommand is of
CommandContainerType, but the CommandContainer inside the
CommandContainerSet is of SequenceContainerType.  Is this an error in the
schema or is there a reason that these CommandContainers are of different
types? 


The reason why there's a CommandContainer inside the CommandContainerSet is
so containers that are used/re-used by many commands could be defined there.
Since these Containers are not associated with any particular MetaCommand
and arguments are local to a MetaCommand, it would be a mistake to allow
them to contain arguments - we wouldn't know which argument to use.

. In version 1.11 of the schema there was an initialValue attribute for a
Parameter in the ParameterSet but this was removed in 1.12.  Now the
initialValue attribute only exists for a ParameterType or ArgumentType.  I
think it would make more sense if the initialValue was a Parameter attribute
and not a ParameterType attribute since there could be multiple instances of
the same ParameterType.  Right now each of these instances would have the
same initialValue but I think what you really want is for each instance to
be able to define its own intialValue if it has one.  Right now if you have
a Type but you want to have different initalValues for it you have to create
multiple Types and I think this makes more work than is really necessary. 


Noted.  I think this is going to be an ongoing debate amoung XTCE
enthusiasts.  Right now the Parameter in ParameterSet is very simple; it is
not 'type' aware.  One of the problems we'd have in giving it an initial
value is that we couldn't type check it by the XML validator.  Because
ParameterType in ParameterTypeSet knows it's type it can type check (i.e.,
the initialValue for an IntegerParameterType will only accept an integer,
the initialValue for a StringParameterType accepts a string ...).

We have discussed two different methods for the identification of container instances: Inheritance and a Combination of Message Key and Choice. The schema now allows for either, but could be simplified by eliminating one or the other. Lockheed recommends eliminating the MessageKey method in favor or inheritance.

Discussion:
We have discussed two different methods for the identification of container instances: Inheritance and a Combination of Message Key and Choice. The schema now allows for either, but could be simplified by eliminating one or the other.  Lockheed recommends eliminating the MessageKey method in favor or inheritance.  Both techniques work and each has its advantages and disadvantages.   Both will remain part of the schema with the potential of dropping one deferred.

Description Kevin Rice 2007-10-22 21:34:53 BST 
Time Association needs to apply to any parameter in a Packet/Container. The
XTCE parameter/parameterproperties/timeassociation can be used to capture an
"offset" time from a packet time stamp.   In CCSDS world, most telemetry
packets are time stamped -- and sometimes those time stamps are adjusted by
some offset or delta for each telemetry parameter in the packet (in effect each
parameter is timetagged).  Since the same parameter may exist in more than one
packet and have different offsets -- the XTCE approach is limiting in this
regard since only one offset can captured per parameter, not at the
packet/container level.  XTCE should modify its container entryList area so
that TimeAssociation can be captured per packet entry.