Issues for XTCE Finalization Task Force
To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 6055: Reed Solomon Encoding and Decoding has no algorithm in the text Jira Issue XTCE-7
Issue 6056: BaseDataType/Enumerated has no holder for allowed name/value pairs Jira Issue XTCE-8
Issue 6057: BaseDataType/Any Jira Issue XTCE-9
Issue 6058: Make capitalization of Elements and Attributes consistent Jira Issue XTCE-10
Issue 6059: Remove obsolete and unreferenced FixedFrameSync Element. Jira Issue XTCE-11
Issue 6060: Drop obsolete FormatType. Jira Issue XTCE-12
Issue 6061: Have all Algorithm Types inherit from a single BaseAlgorithmType Jira Issue XTCE-13
Issue 6062: Have all FrameTypes inherit from a single BaseFrameType Jira Issue XTCE-14
Issue 6063: Change BusAttribute to DataEncoding, have Float, Integer, Enumerated... Jira Issue XTCE-15
Issue 8043: Remove DwellSet replace with indirect parameterRef Summary Jira Issue XTCE-16
Issue 8044: Add time encoding Summary Jira Issue XTCE-17
Issue 8045: Add array types as one of the fundamental types in XTCE Jira Issue XTCE-18
Issue 8046: Specification too complex? Jira Issue XTCE-19
Issue 8047: �shortDescription� size restriction in the NameType is too short Jira Issue XTCE-20
Issue 8048: Parameters that are in multiple sub-systems Summary Jira Issue XTCE-21
Issue 8049: Signed/Unsigned attribute for IntegerDataType Summary Jira Issue XTCE-22
Issue 8050: �minViolations� is misspelled Jira Issue XTCE-23
Issue 8051: Missing �label� in RangeEnumeration Summary Jira Issue XTCE-24
Issue 8052: �SizeRange� in StringDataType is ambiguous Jira Issue XTCE-25
Issue 8053: StringDataType needs a char width Summary Jira Issue XTCE-26
Issue 8054: Ability needed to define a relative time offset within TimeAssociation Jira Issue XTCE-27
Issue 8055: Unique MetaCommand argument names should be enforced Jira Issue XTCE-28
Issue 8056: There needs to be an ability to define an expected rate on containers Jira Issue XTCE-29
Issue 8058: Use schema keyrefs to guarantee references are valid Jira Issue XTCE-30
Issue 8059: Make UnitSet optional Jira Issue XTCE-31
Issue 8060: Remove Altova XML spy diagrams from non normative section. Jira Issue XTCE-32
Issue 8061: Merge the XTCE shemas into a single schema Jira Issue XTCE-33
Issue 6055: Reed Solomon Encoding and Decoding has no algorithm in the text (xtce-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary: Reed Solomon Encoding and Decoding has no algorithm in the text. Suggest providing pseudocode for CCSDS Reed Solomon. Suggest adding that missions may enter their own pseudocode if they wish.
Resolution:
Revised Text: Remove RS Encoding sections and replace in a future XTCE version but a custom algorithm can now be attached to a container for encoding and decoding to accommodate any arbitrary processing. Revised Text: RS encoding algorithm and container type has been removed and deferred to a later version of the specification.
Actions taken:
August 12, 2003: received issue
August 2, 2005: closed issue
Issue 6056: BaseDataType/Enumerated has no holder for allowed name/value pairs (xtce-ftf)
Click here for this issue's archive.
Source: University of Maryland (Dr. Ed Shaya, eshaya(at)umd.edu)
Nature: Enhancement
Severity: Minor
Summary:
BaseDataType/Enumerated has no holder for allowed name/value pairs
Resolution:
Revised Text:
Actions taken:
August 12, 2003: received issue
August 2, 2005: closed issue
Discussion: Add holder for name/value pairs Revised Text: <element name="EnumerationList"> <complexType> <sequence> <element name="Enumeration" type="xtce:ValueEnumerationType" maxOccurs="unbounded"/> </sequence> </complexType> </element
Issue 6057: BaseDataType/Any (xtce-ftf)
Click here for this issue's archive.
Source: University of Maryland (Dr. Ed Shaya, eshaya(at)umd.edu)
Nature: Revision
Severity: Minor
Summary: BaseDataType/Any should be reserved to describe any parameter that can be of any datatype. As it is, it is fixed to be a SourceParameterRef only
Resolution:
Revised Text:
Actions taken:
August 12, 2003: received issue
August 2, 2005: closed issue
Discussion: Resolution: Remove the BaseDataType/Any as it has no purpose that can't be resolved on other manners. Revised Text: BaseDataType/Any is removed
Issue 6058: Make capitalization of Elements and Attributes consistent (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: Make capitalization of Elements and Attributes consistent. According to the formatting rules at the top of the schema, all schema attributes should begin with a lower case letter and all Elements should begin with an upper case letter. This rule is mostly, but not always applied.
Resolution:
Revised Text:
Actions taken:
August 25, 2003: received issue
August 2, 2005: closed issue
Discussion: Schema has been modified to fully apply formatting rules
Issue 6059: Remove obsolete and unreferenced FixedFrameSync Element. (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Minor
Summary: Remove obsolete and unreferenced FixedFrameSync Element. This element is no longer used and is now orphaned
Resolution:
Revised Text:
Actions taken:
August 25, 2003: received issue
August 2, 2005: closed issue
Discussion: Element has been removed
Issue 6060: Drop obsolete FormatType. (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Minor
Summary: Drop obsolete FormatType. This Element/Complex type is no longer used and is now orphaned
Resolution:
Revised Text:
Actions taken:
August 25, 2003: received issue
August 2, 2005: closed issue
Discussion: The complex type has been removed
Issue 6061: Have all Algorithm Types inherit from a single BaseAlgorithmType (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Enhancement
Severity: Minor
Summary: Have all Algorithm Types inherit from a single BaseAlgorithmType. This will simplifiy the schema and will make code auto-generated code from the schema simpler. XML documents compliant with the schema will not change as a result of this schema change.
Resolution:
Revised Text:
Actions taken:
August 25, 2003: received issue
August 2, 2005: closed issue
Discussion: Resolution: All algorithms are now inherited from a single AlgorithmType called Simple AlgorithmType Revised Text: Textual modifications are many - please refer to model differences
Issue 6062: Have all FrameTypes inherit from a single BaseFrameType (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Enhancement
Severity: Minor
Summary: Have all FrameTypes inherit from a single BaseFrameType. This will simplify the schema and any auto generated code generated from the schema. Any XML documents compliant with the schema will not change as a result of this schema change
Resolution:
Revised Text:
Actions taken:
August 25, 2003: received issue
August 2, 2005: closed issue
Discussion: Resolution: All Stream types are now inherited from the high level complex type called 'PCMStreamType' Revised Text: Textual modifications are many - please refer to model differences.
Issue 6063: Change BusAttribute to DataEncoding, have Float, Integer, Enumerated... (xtce-ftf)
Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Enhancement
Severity: Significant
Summary: Change BusAttribute to DataEncoding, have Float, Integer, Enumerated � inherit from AbstractDataType, and make SpaceSystemType, BaseAlgorithmType, ContainerNameType � all inherit from NameDescriptionType
Resolution:
Revised Text:
Actions taken:
August 25, 2003: received issue
August 2, 2005: closed issue
Discussion: Resolution: For purposes of clarity, BusAttribute has been renamed to DataEncoding and all DataTypes are derived from 'AbstractDataType' where 'NumericDataType' is used in between AbstractDataType and the numeric types Integer and Float. All data types, SpaceSystem, Algorithms, and Containers are now derived from 'NameDescriptionType' Revised Text: Textual modifications are many - please refer to model differences.
Issue 8043: Remove DwellSet replace with indirect parameterRef Summary (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Significant
Summary: Remove DwellSet replace with indirect parameterRef Summary: DwellSet as currently implimented is not sufficient for all types of telemetry dwell. A Container Entry type where the entry is given indirectly will simplify the schema and provide a more general Dwell telemetry description
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8044: Add time encoding Summary (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Enhancement
Severity: Significant
Summary: Add time encoding Summary: provide a general mechanism to describe parameters and arguments that are encoded for transmission containing absolute and relative time values.
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8045: Add array types as one of the fundamental types in XTCE (xtce-ftf)
Click here for this issue's archive.
Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov)
Nature: Enhancement
Severity: Significant
Summary: Add array types as one of the fundamental types in XTCE. This addition, once thought to be a �nice� enhancement is now considered essential
Resolution:
Revised Text: Resolution: We had recognized that array handling and structures were almost certainly a needed future capability of the schema, but it was dearly hoped that this could be differed until a future revision. After many repeated requests for Array types, they have been added at the expense, however, of some additional complexity in the schema because before we could create a facility to create arrays, we had to add a facility to create types (so that arrays could be defined as a type). This required a new Collection (ParameterTypeSet and ArgumentTypeSet) in TelemetryMetaData and CommandMetadata. In order to minimize the added complexity, we changed the Parameter and Argument Definitions to be very simple references (the complexity is in the types). The change also required the addition of a new entry type (for array entries) in both the SequenceContainer and the CommandSequenceContainer. Revised Text: <complexType name="ParameterTypeSetType"> <annotation> <documentation xml:lang="en">Holds the list of parameter definitions. A Parameter is a description of something that can have a value; it is not the value itself. </documentation> </annotation> <choice maxOccurs="unbounded"> <element name="StringParameterType" type="xtce:StringDataType"/> <element name="EnumeratedParameterType" type="xtce:EnumeratedDataType"/> <element name="IntegerParameterType"> <complexType> <complexContent> <extension base="xtce:IntegerDataType"> <sequence> <element name="DefaultAlarm" type="xtce:NumericAlarmConditionType" minOccurs="0"/> <element name="ContextAlarmList" minOccurs="0"> <complexType> <sequence> <element name="ContextAlarm" type="xtce:ContextAlarmType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType> </element> <element name="BinaryParameterType" type="xtce:BinaryDataType"/> <element name="FloatParameterType"> <complexType> <complexContent> <extension base="xtce:FloatDataType"> <sequence> <element name="DefaultAlarm" type="xtce:NumericAlarmConditionType" minOccurs="0"/> <element name="ContextAlarmList" minOccurs="0"> <complexType> <sequence> <element name="ContextAlarm" type="xtce:ContextAlarmType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType> </element> <element name="BooleanParameterType" type="xtce:BooleanDataType"/> <element name="RelativeTimeParameterType" type="xtce:RelativeTimeDataType"/> <element name="AbsoluteTimeParameterType" type="xtce:AbsoluteTimeDataType"/> <element name="ArrayParameterType"> <annotation> <documentation>An array type. Will be an array of parameters of the type referenced in 'arrayTypeRef' and have the number of array dimensions as specified in 'numberOfDimensions' </documentation> </annotation> <complexType> <complexContent> <extension base="xtce:NameDescriptionType"> <attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required"/> <attribute name="numberOfDimensions" type="positiveInteger" use="required"/> </extension> </complexContent> </complexType> </element> </choice> </complexType> and <complexType name="ArrayParameterRefEntryType"> <annotation> <documentation>An entry that is an array parameter. This entry is somewhat special because the entry may represent only a part of the Array and it's important to decribe which diminsions of the array come first in the sequence as well as the size of the array.</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <sequence> <element name="DimensionList"> <annotation> <documentation>Where the Dimension list is in this form: Array[1stDim][2ndDim][lastDim]. The last dimension is assumed to be the least significant - that is this dimension will cycle through it's combination before the next to last dimension changes. The order MUST ascend or the array will need to be broken out entry by entry. </documentation> </annotation> <complexType> <sequence> <element name="Dimension" maxOccurs="unbounded"> <annotation> <documentation>For partial entries of an array, the starting and ending index for each dimension, OR the Size must be specified. Indexes are zero based.</documentation> <appinfo>For an ArrayParameterType of size N, their should be N Dimensions</appinfo> <appinfo>An array made up by multiple Entries should not have index's that overlap, but should be continuous.</appinfo> </annotation> <complexType mixed="false"> <sequence> <element name="StartingIndex" type="xtce:IntegerValueType"> <annotation> <documentation>zero based index</documentation> </annotation> </element> <element name="EndingIndex" type="xtce:IntegerValueType"/> </sequence> </complexType> </element> </sequence> </complexType> </element> </sequence> <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/> <attribute name="lastEntryForThisArrayInstance" type="boolean" default="false"/> </extension> </complexContent> </complexType>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8046: Specification too complex? (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Critical
Summary: Early reviewers of the specification have consistently complained that the specification is too complex � particularly in the packaging section and that the annotations that accompany the scheme are oftentimes incomplete, contain typos, or vague.
Resolution:
Revised Text: Resolution: All subsequent changes have been made with simplification in mind. Packaging did have a great deal of complexity strapped onto it to accommodate a variety of special cases. Packaging was re-engineered to accommodate those special cases in an alternative model Revised Text: For simplicity, the entire Packaging section of the schema is shown <!--******** Packaging Schema --> <annotation> <documentation xml:lang="en">This schema definies the dictionary for containers, which in turn describe the physical composition of data in a communication system</documentation> </annotation> <complexType name="ContainerType" abstract="true" mixed="false"> <annotation> <documentation xml:lang="en">An abstract block of data; used as the base type for more specific container types</documentation> </annotation> <complexContent mixed="false"> <extension base="xtce:NameDescriptionType"> <sequence> <annotation> <documentation>RateInStream is used to: a) generate alarms when the Container is updated too frequently or too infrequently, b) provide some 'guidelines' for generating forward link containers, c) provide some guidelines for spacecraft simulators to generate telemetry containers. If necessary, these rates may be defined on a per stream basis.</documentation> <appinfo>The software should check that any Stream names referenced in the RateInStreamSet actually exist.</appinfo> </annotation> <element name="DefaultRateInStream" type="xtce:RateInStreamType" minOccurs="0"/> <element name="RateInStreamSet" minOccurs="0"> <complexType> <sequence> <element name="RateInStream" maxOccurs="unbounded"> <complexType> <complexContent> <extension base="xtce:RateInStreamType"> <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/> </extension> </complexContent> </complexType> </element> </sequence> </complexType> </element> <element name="BinaryEncoding" type="xtce:BinaryDataEncodingType" minOccurs="0"> <annotation> <documentation>May be used to indicate error detection and correction, chage byte order, provide the size (when it can't be derived), or perform some custom processing.</documentation> </annotation> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="SequenceContainerType"> <annotation> <documentation>A list of raw parameters, parameter segments, stream segments, containers, or container segments. Sequence containers may inherit from other sequence containers; when they do, the sequence in the parent SequenceContainer is 'inherited' and if the location of entries in the child sequence is not specified, it is assumed to start where the parent sequence ended. Parent sequence containers may be marked as "abstract". The idle pattern is part of any unallocated space in the Container.</documentation> </annotation> <complexContent> <extension base="xtce:ContainerType"> <sequence> <element name="EntryList" type="xtce:EntryListType"/> <element name="BaseContainer" minOccurs="0"> <complexType> <sequence> <element name="RestrictionCriteria"> <annotation> <documentation>Given that this Container is the Base container type, RestrictionCriteria lists conditions that must be true for this Container to be 'this' subContainer type. May be a simple Comparison List, a Boolean Expression, and/or in a Graph of containers established by the NextContainer</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:MatchCriteriaType"> <choice> <element name="NextContainer" type="xtce:ContainerRefType" minOccurs="0"/> </choice> </extension> </complexContent> </complexType> </element> </sequence> <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/> </complexType> </element> </sequence> <attribute name="abstract" type="boolean"/> <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0x0"/> </extension> </complexContent> </complexType> <complexType name="SequenceEntryType"> <annotation> <documentation>An abstract type used by sequence containers. An entry contains a location in the container. The location may be either fixed or dynamic, absolute (to the start or end of the enclosing container, or relative (to either the previous or subsequent entry). Entries may also repeat.</documentation> </annotation> <sequence> <element name="LocationInContainerInBits" minOccurs="0"> <annotation> <documentation>If no LocationInContainer value is given, the entry is assumed to begin immediately after the previous entry.</documentation> </annotation> <complexType> <complexContent> <extension base="xtce:IntegerValueType"> <attribute name="referenceLocation" default="previousEntry"> <annotation> <documentation>The location may be relative to the start of the container (containerStart), relatitive to the end of the previous entry (previousEntry), relative to the end of the container (containerEnd), or relative to the entry that follows this one (nextEntry). If going forward (containerStart and previousEntry) then, then the location refers to the start of the Entry. If going backwards (containerEnd and nextEntry) then, the location refers to the end of the entry.</documentation> </annotation> <simpleType> <restriction base="string"> <enumeration value="containerStart"/> <enumeration value="containerEnd"/> <enumeration value="previousEntry"/> <enumeration value="nextEntry"/> </restriction> </simpleType> </attribute> </extension> </complexContent> </complexType> </element> <element name="RepeatEntry" type="xtce:RepeatType" minOccurs="0"> <annotation> <documentation xml:lang="en">May be used when this entry repeats itself in the sequence container. If not supplied, the entry does not repeat.</documentation> </annotation> </element> <element name="IncludeCondition" type="xtce:MatchCriteriaType" minOccurs="0"> <annotation> <documentation>This entry will only be included in the sequence when this condition is true. If no IncludeCondition is given, then it is will be included. A parameter that is not included will be treated as if it did not exist in the sequence at all.</documentation> </annotation> </element> </sequence> </complexType> <complexType name="ContainerRefType"> <annotation> <documentation xml:lang="en">Holds a reference to a container</documentation> </annotation> <attribute name="containerRef" type="xtce:NameReferenceType" use="required"> <annotation> <documentation xml:lang="en">name of container</documentation> </annotation> </attribute> </complexType> <complexType name="MessageRefType"> <annotation> <documentation xml:lang="en">Holds a reference to a message</documentation> </annotation> <attribute name="messageRef" type="xtce:NameReferenceType" use="required"> <annotation> <documentation xml:lang="en">name of container</documentation> </annotation> </attribute> </complexType> <complexType name="ServiceType"> <annotation> <documentation xml:lang="en">Holds a set of services, logical groups of containers OR messages (not both).</documentation> </annotation> <complexContent> <extension base="xtce:NameDescriptionType"> <sequence> <element name="MessageRefSet" minOccurs="0"> <complexType> <sequence> <element name="MessageRef" maxOccurs="unbounded"/> </sequence> </complexType> </element> <element name="ContainerRefSet"> <complexType> <sequence> <element name="ContainerRef" type="xtce:ContainerRefType" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> </extension> </complexContent> </complexType> <complexType name="ContainerSetType"> <annotation> <documentation>Unordered Set of Containers</documentation> </annotation> <choice maxOccurs="unbounded"> <element name="SequenceContainer" type="xtce:SequenceContainerType"> <annotation> <documentation>SequenceContainers define sequences of parameters or other containers. </documentation> </annotation> </element> </choice> </complexType> <complexType name="EntryListType" mixed="false"> <annotation> <documentation>Contains an ordered list of Entries. Used in Sequence Container</documentation> </annotation> <choice minOccurs="0" maxOccurs="unbounded"> <element name="ParameterRefEntry" type="xtce:ParameterRefEntryType"/> <element name="ParameterSegmentRefEntry" type="xtce:ParameterSegmentRefEntryType"/> <element name="ContainerRefEntry" type="xtce:ContainerRefEntryType"/> <element name="ContainerSegmentRefEntry" type="xtce:ContainerSegmentRefEntryType"/> <element name="StreamSegmentEntry" type="xtce:StreamSegmentEntryType"/> <element name="IndirectParameterRefEntry" type="xtce:IndirectParameterRefEntryType"/> <element name="ArrayParameterRefEntry" type="xtce:ArrayParameterRefEntryType"/> </choice> </complexType> <complexType name="ParameterRefEntryType"> <annotation> <documentation>An entry that is a single Parameter</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/> </extension> </complexContent> </complexType> <complexType name="ParameterSegmentRefEntryType"> <annotation> <documentation>An entry that is only a portion of a parameter value indicating that the entire parameter value must be assembled from other parameter segments. It is assumed that parameter segments happen sequentially in time, that is the first part if a telemetry parameter first, however (and there's always a however), if this is not the case the order of this parameter segment may be supplied with the order attribute where the first segment order="0".</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/> <attribute name="order" type="positiveInteger"/> <attribute name="sizeInBits" type="positiveInteger" use="required"/> </extension> </complexContent> </complexType> <complexType name="ContainerRefEntryType"> <annotation> <documentation>An entry that is simply a reference to another container.</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/> </extension> </complexContent> </complexType> <complexType name="ContainerSegmentRefEntryType"> <annotation> <documentation>An entry that is only a portion of a parameter value indicating that the entire parameter value must be assembled from other parameter segments. It is assumed that parameter segments happen sequentially in time, that is the first part if a telemetry parameter first, however (and there's always a however), if this is not the case the order of this parameter segment may be supplied with the order attribute where the first segment order="0".</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/> <attribute name="order" type="positiveInteger"/> <attribute name="sizeInBits" type="positiveInteger" use="required"/> </extension> </complexContent> </complexType> <complexType name="StreamSegmentEntryType"> <annotation> <documentation>An entry that is a portion of a stream (streams are by definition, assumed continuous) It is assumed that stream segments happen sequentially in time, that is the first part if a steam first, however, if this is not the case the order of the stream segments may be supplied with the order attribute where the first segment order="0".</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/> <attribute name="order" type="positiveInteger"/> <attribute name="sizeInBits" type="positiveInteger" use="required"/> </extension> </complexContent> </complexType> <complexType name="IndirectParameterRefEntryType"> <annotation> <documentation>An entry whose name is given by the value of a ParamameterInstance. This entry may be used to implement dwell telemetry streams. The value of the parameter in ParameterInstance must use either the name of the Parameter or its alias. If it's an alias name, the alias namespace is supplied as an attribute.</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <sequence> <element name="ParameterInstance" type="xtce:ParameterInstanceRefType"/> </sequence> <attribute name="aliasNameSpace" type="string"/> </extension> </complexContent> </complexType> <complexType name="ArrayParameterRefEntryType"> <annotation> <documentation>An entry that is an array parameter. This entry is somewhat special because the entry may represent only a part of the Array and it's important to decribe which diminsions of the array come first in the sequence as well as the size of the array.</documentation> </annotation> <complexContent> <extension base="xtce:SequenceEntryType"> <sequence> <element name="DimensionList"> <annotation> <documentation>Where the Dimension list is in this form: Array[1stDim][2ndDim][lastDim]. The last dimension is assumed to be the least significant - that is this dimension will cycle through it's combination before the next to last dimension changes. The order MUST ascend or the array will need to be broken out entry by entry. </documentation> </annotation> <complexType> <sequence> <element name="Dimension" maxOccurs="unbounded"> <annotation> <documentation>For partial entries of an array, the starting and ending index for each dimension, OR the Size must be specified. Indexes are zero based.</documentation> <appinfo>For an ArrayParameterType of size N, their should be N Dimensions</appinfo> <appinfo>An array made up by multiple Entries should not have index's that overlap, but should be continuous.</appinfo> </annotation> <complexType mixed="false"> <sequence> <element name="StartingIndex" type="xtce:IntegerValueType"> <annotation> <documentation>zero based index</documentation> </annotation> </element> <element name="EndingIndex" type="xtce:IntegerValueType"/> </sequence> </complexType> </element> </sequence> </complexType> </element> </sequence> <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/> <attribute name="lastEntryForThisArrayInstance" type="boolean" default="false"/> </extension> </complexContent> </complexType> <complexType name="RateInStreamType"> <annotation> <documentation>Used in packaging to define the expected rate that any individual container will be in a Stream</documentation> </annotation> <attribute name="basis" default="perSecond"> <simpleType> <restriction base="string"> <enumeration value="perSecond"/> <enumeration value="perContainerUpdate"/> </restriction> </simpleType> </attribute> <attribute name="minimumValue" type="double"/> <attribute name="maximumValue" type="double"/> </complexType> <!--******** End of Packaging Schema -->
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8047: �shortDescription� size restriction in the NameType is too short (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Significant
Summary: �shortDescription� size restriction in the NameType is too short. Summary: 'shortDescription� size restriction in the NameType is too short
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Resolution: Size restriction was removed, but an annotation in the schema was added that strongly suggested that the size be kept under 80 characters. This change will not have any impact on existing XML documents. Revised Text: <attribute name="shortDescription" type="string" use="optional"> <annotation> <documentation>It is strongly recommended that the short description be kept under 80 characters in length</documentation> </annotation> </attribute>
Issue 8048: Parameters that are in multiple sub-systems Summary (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Minor
Summary: Parameters that are in multiple sub-systems Summary: ITOS frequently has parameters that are considered members of multiple sub-systems, the adopted XTCE format only allows Parameters to be members of a single sub-system
Resolution:
Revised Text: Resolution: The definition of ParameterSetType was expanded to allow the inclusion of a ParameterRef, thus allowing a reference to a previously defined Parameter in any SpaceSystem (to include sub-systems). This change will not have any impact on existing XML documents. Revised Text: <element name="ParameterRef" type="xtce:ParameterRefType"/> and <element name="MetaCommandRef" type="xtce:NameReferenceType">
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8049: Signed/Unsigned attribute for IntegerDataType Summary (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Minor
Summary: Signed/Unsigned attribute for IntegerDataType Summary: The Integer Data Type requires an attribute to indicate whether this Data should be treated as a signed or unsigned integer. Missions may need the extra bit for large data values.
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Resolution: A signed attribute was added. This change will not have any impact on existing XML documents. Revised Text: <attribute name="signed" type="boolean" default="true"/>
Issue 8050: �minViolations� is misspelled (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: �minViolations� is misspelled The attribute �minViolations� in the complex type NumericAlarmContions is spelled minVioatons�. This change will only impact XML documents that use the misspelled �minVioatons� attribute.
Resolution:
Revised Text: Resolution: Fixed. Revised Text: <attribute name="minViolations" type="integer" default="1"/>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8051: Missing �label� in RangeEnumeration Summary (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: Missing �label� in RangeEnumeration Summary: The label in the ToStringCalibrator for RangeEnumeration is missing
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Resolution: As in other Enumeration types, 'label' was added. This change will only impact XML documents that use RangeEnumeration. Revised Text: <attribute name="label" type="string" use="required"/>
Issue 8052: �SizeRange� in StringDataType is ambiguous (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: �SizeRange� in StringDataType is ambiguous �SizeRange� in StringDataType is ambiguous because it�s unclear if the size is in characters, or bytes, or bits or something else. This Element name violates one of the XTCE conventions �Hints on units (for values with units) are provided in the names of attributes�.
Resolution:
Revised Text: Resolution: Rename 'SizeRange' to SizeRangeInCharacters. This change will only impact XML documents that use the SizeRange. Revised Text: <element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8053: StringDataType needs a char width Summary (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: The StringDataType needs a character width attribute to be used by the ground software when it is necessary to handle multi-byte characters.
Resolution:
Revised Text: Resolution: A characterWidth attribute was added. Revised Text: <attribute name="characterWidth"> <simpleType> <restriction base="integer"> <enumeration value="8"/> <enumeration value="16"/> </restriction> </simpleType> </attribute>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8054: Ability needed to define a relative time offset within TimeAssociation (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Minor
Summary: Ability needed to define a relative time offset within TimeAssociation Summary: The �TimeAssociationType� provides a means for ParameterInstances to be tied to a time value, but this time association also needs to have an optional relative time offset.
Resolution:
Revised Text: Resolution: An 'offset' attribute was added. This change will not have any impact on XML documents. Revised Text: <attribute name="offset" type="date"> <annotation> <documentation source="The offset is used to supply a relative time offset from the time association and to this parameter"/> </annotation> </attribute>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8055: Unique MetaCommand argument names should be enforced (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: Within a MetaCommand, the uniqueness of argument names can be enforced by the schema language and should be.
Resolution:
Revised Text: Resolution: A key to MetaCommand was added which will enforce Argument name uniqueness. This change will not have any impact on XML documents. Revised Text: <key name="ArgumentNameKey"> <selector xpath="xtce:ArgumentList/*"/> <field xpath="@name"/> </key>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8056: There needs to be an ability to define an expected rate on containers (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Significant
Summary: This rate will be used to generate an alarm if certain telemetry containers do not arrive at the anticipated rate. This rate could also be used by simulators (for generating telemetry) or as guides for generating forward link containers
Resolution:
Revised Text: Resolution: A 'RateInContainer' sequence was added to 'ContainerType'. This change will not require changes to existing XML documents. Revised Text: <sequence> <annotation> <documentation>RateInStream is used to: a) generate alarms when the Container is updated too frequently or too infrequently, b) provide some 'guidelines' for generating forward link containers, c) provide some guidelines for spacecraft simulators to generate telemetry containers. If necessary, these rates may be defined on a per stream basis.</documentation> <appinfo source="The software should check that any Stream names referenced in the RateInStreamSet actually exist."/> </annotation> <element name="DefaultRateInStream" type="xtce:RateInStreamType" minOccurs="0"/> <element name="RateInStreamSet" minOccurs="0"> <complexType> <sequence> <element name="RateInStream" maxOccurs="unbounded"> <complexType> <complexContent> <extension base="xtce:RateInStreamType"> <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/> </extension> </complexContent> </complexType> </element> </sequence> </complexType> </element> </sequence>
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Issue 8058: Use schema keyrefs to guarantee references are valid (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: If items like Parameters, and MetaCommands, Containers, and Algorithms were given a unique id then references to those objects could be guaranteed to be correct by the XML parsers
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Discussion: However, in assigning a unique id to these objects we would loose all of the benefits of the hierarchical structure of SpaceSystem. Disposition: Closed, no change
Issue 8059: Make UnitSet optional (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Revision
Severity: Minor
Summary: Currently an Empty UnitSet is required for all data types even when there are no units. This adds significant extra text to an XML document that validates to the XTCE schema.
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Resolution: Do to the current sensitivity about engineering units at NASA, it was decided to leave this in to serve as a reminder that units should be added if they exist. No change. Revised Text: None. Disposition: Closed, no change
Issue 8060: Remove Altova XML spy diagrams from non normative section. (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Clarification
Severity: Minor
Summary: Reason: The auto-generated documentation may be generated by anyone and makes the non-normative specification difficult to manage and extraordinarily large. UML diagrams in the document serve the same purpose
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Resolution: Diagrams are removed
Issue 8061: Merge the XTCE shemas into a single schema (xtce-ftf)
Click here for this issue's archive.
Source: Real Time Logic Inc. (Mr. Charles Gerry Simon, Gerry.Simon(at)kratosdefense.com)
Nature: Enhancement
Severity: Significant
Summary: The normative XML schema component of the specification is broken into separate W3C schemas. While this is a valid approach by the W3C schema specification, many (most?) of the currently available XML validation tools do not gracefully handle multiple schemas. This change will have no effect on compliant XML documents
Resolution:
Revised Text:
Actions taken:
December 31, 2004: received issue
August 2, 2005: closed issue
Discussion: Resolution: This was actually the first change made to the Adopted specification but, it was never formally documented. The once separate schemas have been combined into a single schema called "SpaceSystem1.0.xsd" Revised Text: Except for the header and trailer in each separate file being removed, the text from the separate files is unchanged