Issues for Mailing list of the XTCE Revision Task Force

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

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

Issue 8703: XTCE issue - add shortDescription to EntryList entries
Issue 8704: XTCE issue: dimensionList in arrayParameterRef should be optional
Issue 8875: proposed schema change for documentation issue
Issue 8885: includeCondition in commandContainer issue
Issue 8886: repeat of arguments issue
Issue 8905: lack of delta limits (MER + JWST)
Issue 8906: command side seems to be missing the ability to have repeat arguments (MER)
Issue 8907: command side unable to describe "packed commands"
Issue 8908: inability to describe sets of limits (alarms) and conversions (polynomials)
Issue 8909: lack of Union construct (MER + ASIST)
Issue 8910: lack of clean way to describe "system variables",
Issue 8911: lack of clean way to describe multiple documentary type items
Issue 8912: no tracking mechanism per PARAMETER for changes (no change log)
Issue 8913: Variable length command packets must be supported
Issue 8914: JPL MER schema supports "hardware commands
Issue 8915: JWST, non-CCSDS header commands, routing info
Issue 8916: XTCE Command "Permissions" model may not be generic enough
Issue 8923: proper reference formed weak
Issue 8924: Container/Argument/Stream/Type/etc
Issue 8925: Clarification is needed on Ref names "local" to a spaceSystem
Issue 8926: Ref rules should be spelled out
Issue 8927: Xpath:
Issue 8928: sizeInBits
Issue 8959: Propose that XCTE ( at this point ) will be limited to exchange data
Issue 8960: too much leeway how to use the standard
Issue 8961: USE CCSDS examples how to use the standard
Issue 8962: Spec too complex?
Issue 9025: "Command Processing" box
Issue 9026: Contents"
Issue 9027: "Foreword", 2nd last line
Issue 9028: "Foreword", line 2.
Issue 9029: "Parameter Processing" box
Issue 9030: DC-004 "Philosophy", line 2
Issue 9031: MK-001 A mistake of attribute[messageRef]'s annotation
Issue 9032: MK-003 A mistake of type[ContainerSegmentRefEntryType]'s annotation
Issue 9033: AO-006 Additional examples (2)
Issue 9034: MK-010 All ParameterType and ArgumentType should have alarm element
Issue 9035: DC-028 ArgumentList
Issue 9036: DC-017 Assembly / dissembly information.
Issue 9037: DC-021 Assembly / dissembly of streams
Issue 9038: HVM-004 Data Encoding definitions
Issue 9039: MS-009 De-calibration of cmd parameters?
Issue 9040: MK-007 Don't need element[ChangePerSecondAlarmConditions]
Issue 9041: MP-007 Dynamic telemetry check types
Issue 9042: DC-026 Encoding area
Issue 9043: DC-025 Encoding information
Issue 9044: DC-005 Figure
Issue 9045: DC-015 Figure label.
Issue 9046: DC-011 Figure text.
Issue 9047: MS-006 Footing of Figure 1 is missing.
Issue 9048: DC-029 Line 1
Issue 9049: DC-010 Line 1
Issue 9050: DC-018 Line 10
Issue 9051: DC-034 Line 10
Issue 9052: DC-032 Line 3
Issue 9053: DC-027 Line 3
Issue 9054: DC-023 Line 3.
Issue 9055: DC-008 Line 4
Issue 9056: DC-020 Line 4
Issue 9057: DC-016 Line 4.
Issue 9058: DC-030 Line 5
Issue 9059: DC-012 Line 5
Issue 9060: DC-024 Line 6
Issue 9061: DC-009 Line 6
Issue 9062: DC-033 Line 6
Issue 9063: MP-004 Logarithmic calibrations
Issue 9064: MS-003 Meaning not clear.
Issue 9065: MS-001 Missing page numbering
Issue 9066: DC-013 Parameter encoding information
Issue 9067: V-003 Schema file identification
Issue 9068: MK-005 Should use type[ContextCalibratorType] in …
Issue 9069: Should use type[FixedFrameSyncStrategyType] in type [FixedFrameStreamType]
Issue 9070: TH-001 Some Typos
Issue 9071: MP-001 Terminology
Issue 9072: MK-002 Type of element[MessageRef] is undefined
Issue 9073: MM-001 What missions need
Issue 9083: Section: 7
Issue 9199: CalibratorType
Issue 9200: CalibratorType (02)
Issue 9201: CalibratorType (03)
Issue 9202: SplineCalibrator
Issue 9203: ToString and Booleans
Issue 9204: CalibratorType
Issue 9205: NumericAlarmConditionTy
Issue 9206: CommandContainerType
Issue 9207: MetaCommand
Issue 9208: Command/Parameter
Issue 9209: Verifiers
Issue 9210: Command verifiers
Issue 9211: ArgumentType / ValidRange
Issue 9212: UnitSet
Issue 9213: ParameterType
Issue 9214: Algorithm for derived
Issue 9215: Argument set
Issue 9216: CommandContainer/Entry
Issue 9217: BlockMetaCommandType
Issue 9218: Parameters
Issue 9219: SpaceSystemType
Issue 9220: Aliases
Issue 9221: OnBoard Memory
Issue 9222: OnBoard Software
Issue 9223: NameType
Issue 10153: 1 - move initialValue and UnitSet to ParameterSet (ESA-08)
Issue 10154: Expand explanatory material
Issue 10155: Expand explanatory material related to "Figure 2"
Issue 10156: 4 -- Expand explanatory material related to "Figure 4"
Issue 10157: 5 -- Expand explanatory material related to "Figure 6"
Issue 10158: 6 - Add Delta Alarms to XTCE
Issue 10159: 7 - Expand explanatory material related to "Figure 2"
Issue 10160: 8 - Expand explanatory material related to "Figure 3"
Issue 10161: 9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type
Issue 10162: 10 - Add indicator of operational status to XTCE (JPL-004)
Issue 10163: Change service set to either accept Messages or Container references
Issue 10164: 2 - Add Aggregate (similar to C-structure) type to XTCE
Issue 10165: Expand explanatory material for XTCE types
Issue 10166: 4 -- Add a name/short description to the argument's valid range set
Issue 10167: 5 - Expand explanatory material in Figure 1
Issue 10168: 6 - Figures 2-10 not referenced in text
Issue 10169: 1 - Support ability to describe redundant or complimentary data
Issue 10170: - Add separate CalibratorSet to XTCE
Issue 10171: 3 - Use UML Instance diagrams for XTCE document example
Issue 10172: 4 - Separate XTCE Schema into constituent parts
Issue 10173: 5 - Align XTCE and CCSDS Navigation Schemas (types)
Issue 10174: 6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types
Issue 10175: 7 - Use UUIDs instead of current XTCE Referencing mechanism
Issue 10176: 8 - Add activity field to Alarms to indicate what the alarm will trigger
Issue 10177: 9 - Add filtering of value threshold to maintain telemetry at certain rates
Issue 10178: 1 - Add ability to describe general equations in Calibrator area
Issue 10179: NASA-013
Issue 10180: ESA-002
Issue 10181: ESA-010
Issue 10182: ESA-012
Issue 10183: ESA-013
Issue 10184: ESA-017
Issue 10185: ESA-018
Issue 10186: ESA-019
Issue 10187: ESA-020
Issue 10188: ESA-022
Issue 10189: ESA-023
Issue 10190: ESA-025
Issue 10191: ESA-042
Issue 10192: ESA-054
Issue 10193: ESA-055
Issue 10194: ESA-056
Issue 10195: ESA-065
Issue 10196: ESA-067
Issue 10197: ESA-068
Issue 10198: ESA-069
Issue 10199: ESA-072
Issue 10200: ESA-075
Issue 10201: ESA-077
Issue 10202: ESA-078
Issue 10203: ESA-079
Issue 10204: INPE-001
Issue 10205: INPE-003
Issue 10206: INPE-006
Issue 10207: INPE-007
Issue 10208: INPE-012
Issue 10209: INPE-013
Issue 10210: JPL-001
Issue 10211: JPL-002
Issue 10212: JPL-005
Issue 10213: JPL-006
Issue 10214: JPL-007
Issue 10215: JPL-008
Issue 10216: JPL-009
Issue 10217: JPL-010
Issue 10218: JPL-011
Issue 10219: JPL-012
Issue 10220: JPL-013
Issue 10221: JPL-014
Issue 10222: JPL-015
Issue 10223: JPL-017
Issue 10224: JPL-018
Issue 10225: JPL-019
Issue 10226: JPL-020
Issue 10227: JPL-021
Issue 10228: JPL-022
Issue 10229: JPL-023
Issue 10230: JPL-024
Issue 10231: JPL-025
Issue 10232: JPL-027
Issue 10233: JPL-028
Issue 10234: JPL-031
Issue 10235: ESA-003
Issue 10236: ESA-021
Issue 10237: ESA-024
Issue 10238: ESA-027
Issue 10239: ESA-028
Issue 10240: ESA-029
Issue 10241: ESA-030
Issue 10242: ESA-031
Issue 10243: ESA-033
Issue 10244: ESA-035
Issue 10245: ESA-036
Issue 10246: ESA-037
Issue 10247: ESA-043
Issue 10248: ESA-044
Issue 10249: ESA-046
Issue 10250: ESA-047
Issue 10251: ESA-049
Issue 10252: ESA-050
Issue 10253: ESA-051
Issue 10254: ESA-052
Issue 10255: ESA-057
Issue 10256: ESA-058
Issue 10257: ESA-059
Issue 10258: ESA-060
Issue 10259: ESA-061
Issue 10260: ESA-062
Issue 10261: ESA-063
Issue 10262: ESA-064
Issue 10263: ESA-066
Issue 10264: ESA-070
Issue 10265: ESA-073
Issue 10266: ESA-074
Issue 10267: ESA-076
Issue 10268: INPE-002
Issue 10269: INPE-004
Issue 10270: INPE-005
Issue 10271: INPE-008
Issue 10272: INPE-010
Issue 10273: INPE-011
Issue 10274: NASA-002
Issue 10275: NASA-003
Issue 10276: NASA-005
Issue 10277: NASA-007
Issue 10278: NASA-008
Issue 10279: NASA-009
Issue 10280: NASA-011
Issue 10281: NASA-012
Issue 10440: Division symbol
Issue 12803: Some sections/pages refer to the old (1.0) xsd version
Issue 14450: Clear Up Calibrated/Uncalibrated Values in Schema
Issue 14451: Create RangeEnumeration Type
Issue 14452: Add ability to compare counters in IncludeCondition
Issue 14453: Fix ArgumentTypes child element or attributes that use the term Parameter, to Argument
Issue 14454: Move Alarms outside of Type Area
Issue 14455: Move array sizing to Parameter and Argument from container area
Issue 14456: Label Missing in IntegerType/RangeEnumeration area
Issue 14457: ContextAlarm not set to Inf Elements in EnumerationType
Issue 14458: Checkwindow not tied to context
Issue 14459: ErrorDetectCorrect does not support Checksum
Issue 14460: Message/IncludeCondition/BaseContainer similarity
Issue 14461: Put Alarms in Arguments; leaves Alarms in Command Parameters
Issue 14462: Message/ContainRef should read ContainerRef
Issue 14463: TimeAssociation schema type is incorrect
Issue 14465: AlarmType produces problem in JaxB
Issue 14466: AbsoluteTime should have Alarms
Issue 14467: MathOperator needs to be cleaned up
Issue 14468: Clarify ContainerRef check in Verification area
Issue 14469: Clean up Annotation Related to Verifiers
Issue 14470: PercentComplete in Verifiers needs clean up
Issue 14471: Change UnitSet to optional
Issue 14472: Change UnitSet to simple String; change name
Issue 14473: Add forward/reverse calibrator metadata
Issue 14474: Unify metacommand/commandContainer and commandContainerSet/commandcontainer schema types
Issue 14475: Autogenerator issue with schema type derivation
Issue 14476: Align ArgumentType and ParameterType construction
Issue 14477: Move ValidRangeAppliesToCalibrated Attribute
Issue 14478: StringDataType UTF-8/CharacterWidth Issue
Issue 14479: Key bugs
Issue 14480: Add name attribute to context alarms or calibrators
Issue 14481: Generalize array type, add attribute for ROW or COL order
Issue 14482: Explain interaction of dynamic value and segments, array lastEntryForThisArray
Issue 14483: Add explanatory annotation that MetaCommand/CommandContainer is semantically similar to a Java Private Inner Class
Issue 14484: Use of the include conditions
Issue 14485: packet identification
Issue 14486: relative path in the parameterRef
Issue 14487: SplinePoint attribute order should be ignored (typo)
Issue 14488: size in bits of float encoding
Issue 14489: Expand NameReference semantics
Issue 14490: Remove old comments
Issue 14491: *Container@abstract should have default of false
Issue 14492: DefaultSignicance element can have no content at all
Issue 14493: MessageSet has unneeded attribute
Issue 14494: InputOutputTriggerAlgorithmType@triggerContainer is a NameType, should it be a NameReference?
Issue 14495: InputOutputAlgorithm@thread optional boolean, should have default of false
Issue 14496: toString/NumberFormat needs default settings
Issue 14497: toString/NumberFormat needs default settings
Issue 14498: Derive ArgumentTypes by extension
Issue 14499: *Type/@initialValue need clarifications
Issue 14500: FixedValueEntry@sizeInBits should be required
Issue 14501: attribute twosCompliment should be twosComplement
Issue 14502: Time/Encoding@scale,@offset terminology vs DynamicValue/LinearAdjust
Issue 14503: FloatEncoding float formats -- MIL1750a, IEEE, bit size issues
Issue 14504: AlgorithmSet missing algorithms
Issue 14505: CustomAlgorithm should be "typed" reference to AlgorithmSet
Issue 14506: Should RestrictionCriteria should be assignment not operators for Commanding?
Issue 14507: Add OCL specific Algorithm to XTCE
Issue 14508: Condition has two elements with the same name, causes problems for some autogenerators
Issue 14509: Clean up semantics of "OO-Include Condition"
Issue 14510: RelativeTimeType nomenclature conflicts with RelativeTimeParameterType
Issue 14511: IndirectParameterEntry should have segment varient?
Issue 14512: ChangeAlarmRates confusing and ambiguous
Issue 14513: inside/outside alarms not supported
Issue 14514: remove extraneous keys or uniq
Issue 14515: ErroCorrectDetect -- Parity
Issue 14516: exponent attribute in Term element in PolynomialCalibrator should be non-negative integer
Issue 14517: ByteOrderList is invalid for Containers
Issue 14518: In EnumerationAlarm, enumerationValue should called enumerationLabel
Issue 15858: EnumeratedParameterType does not support multiple context alarms
Issue 15874: EnumeratedParameterType does not support multiple context alarms
Issue 16721: Adding structure to Parameters
Issue 16722: Need a ParameterProperty for "observability" or "change only threshold"
Issue 17405: <LocationInContainerInBits>
Issue 17416: No short description or long description at the Member element of AggregateParameterType or AggregateArgumentType
Issue 17417: AggregateParameterType or AggregateArgumentType Member attribute 'typeRef' is vague
Issue 17418: Member of an AggregateParameterType or AggregateArgumentType can't be an ArrayParameterType or ArrayArgumentType
Issue 17419: At the Parameter element, initial values for Array or Aggregates may not be set.
Issue 17421: The XTCE element MetaCommand has a child element called VerifierSet
Issue 17422: element ParameterInstanceRefOperand in the MathOperationType
Issue 18537: SplineCalibrator order attribute too restrictive
Issue 18540: Enumeration element could use an @shortDescription

Issue 8703: XTCE issue - add shortDescription to EntryList entries (xtce-rtf)

Items in entryList should each have their own optional shortDescription attribute for documentation at each entry of the container itself.

Specifying array dimension sizes in arrayParameterRef should be optional.  In telemetry arrays often include an on the fly 'count' in the data packet.  Therefore this may come in conflict with the fixed sizes in the dimension list.
 
The other option is to clearly state in the annotation that the dimensionList is mearly an hint to the run-time software and more more processing will need to be done to ascertain the true size.
 
Finally, a further option would be to have the dimensionList optionally look up the dimension size using a InstanceRef to another parameter in the data stream...

JPL MER & JWST schemas have numerous ways to capture various types of documentation -- these include but are not limited to developer information, flight software information,  document info and so forth.  At this time XTCE has a LongDescription and ShortDescription and a few specialized areas of documentation -- that are simply not sufficient to capture the full scope of info held in the other schemas.   While it would be nice to specifically put elements into XTCE to allow the capture of this information in a formal way, there is at this time no agreement on what that would exactly be.   
 
Most of the information in question is of the form "tag: data" -- where the tag is simply the label for the data -- such as "Developer:  T.Hacker".   As such a simpler solution at the moment would be to extend the XTCE LongDescription to be unbounded and add an attribute to it to hold the tag information.  Because this element is part of a base type in XTCE used by most of the major types -- it will give users a large number of areas in which to capture their varied documentation.  In time as agreement is reached on specific types of documentation, the schema can be extended more formally..
 
--- Proposed Schema change to XTCE ---

 
<element name="LongDescription" minOccurs="0" maxOccurs="unbounded">

<annotation>

    <documentation>The Long Description is intended to be used for explanitory descriptions of the object and may include HTML markup. Long Decriptions are of unbounded length. Multiple long descriptions may be used to hold tagged information.</documentation>

</annotation>

<complexType>

<simpleContent>

<extension base="string">

<attribute name="name" type="string"/>

</extension>

</simpleContent>

</complexType>

</element>

Resolution:
A new Element "AncillaryData" was added to "NameDescriptionType" to address this issue.  NameDescription Type is the base type for Parameter, ParameterType, ArgumentType, Argument, ContainerType, Algorithm … basically all significant elements.  AncillaryData is itself contained within a 'Set' and is unbounded.  AncillaryData is named (so that each organization may uniquely name their set of AncillaryData, has a mimeType and an optional href to point to possible external data.  AncillaryData may be used for very simple data like CVS tags to complex data like sound files or even external applications. 

In metacommand container/commandContainer - the includeCondition only allows parameterRef,  it should also allow argumentRef.  
 
Here is an example from a simulated MER command that uses either an ARM or Elbow argument depending on the proceeding argument which is the motor_id... the arguments are different units as well.
 
-----
 
<CommandContainer name="CMD-MOTOR_Container">
 <EntryList>
  <ArgumentRefEntry argumentRef="motor_id"/>
  <ArgumentRefEntry argumentRef="distanceArm">
   <IncludeCondition>
    <Comparison parameterRef="motor_id" value="0"/>
   </IncludeCondition>
  </ArgumentRefEntry>
  <ArgumentRefEntry argumentRef="distanceElbow">
   <IncludeCondition>
    <Comparison parameterRef="motor_id" value="1"/>
   </IncludeCondition>
  </ArgumentRefEntry>
 </EntryList>
</CommandContainer>

Resolution:
The Container inheritance feature can be used to implement this requested feature.

The following command makes use of a repeat block of arguments:
 
ack_packets ( num_acks,  ack_block )
 
Ack_block consists of three arguments:  pkt_start, pkt_end and pkt_time
 
This would be a perfectly valid command:
 
ack_block[0].pkt_start = 1
ack_block[0].pkt_end = 1
ack_block[0].pkt_time = 00:00:00
 
ack_packets ( 1, ack_block )
 
----
 
This is not capturable in XTCE because there is no mechanism for having REPEATS of ARGUMENTS.
 
There are workarounds but there are less than ideal, they are:
 
-- use an array,  this is problematic because the types of each sub-field may be different (see above, pkt_time is a TIME type)
-- treat them as parameters... which they are not...

Resolution:
Use parameters in the command area instead of arguments as a workaround.  This feature may be considered for a future revision.

Delta limits compare deltas between instances of a parameter and issue an alarm outside a certain threshold

This issue is a duplicate of  issue 10158 which is resolved.

CommandContainerSet does not have argumentRefEntry

Resolution:
Duplicate of 8886 which is deferred, since an expression of the desired capability is possible in XTCE using parameter references.  Originally it was thought CommandContainerSet should have argumentRefs,  however this was a misunderstanding of the area

command side unable to describe "packed commands" where multiple commands are packed into a single packet (MER)
 
It isn't clear metacommand which itself represents a command in XTCE can package more than one command.  Essentially this is multiple commands stuffed in a single packet

Resolution:
XTCE is not constrained to one command per packet.  A packed command packet could be composed of any number of arbitrary CommandContainers.  XTCE lacks rules on when to transmit a packed Command Container, but the utility of adding those rules to the exchange format has to be traded against additional complexity.

inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase  (JWST)
 
JWST hold conversion and limits in a seperate file that are grouped.  Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate.  XTCE allows one to specify at MOST one of each of these per parameterType

Resolution:
There are really two separate issues here: 1) the need different alarms and calibrations in different phases and 2) the desire to use alarm or calibrator sets and refer to these sets in each parameter - to reduce redundancy.  Each of these sub-issues is addressed below:

1.	Alarms and Phases.  This is simply a nomenclature issue; what is called a mission phase here (and in many Boeing missions) is in XTCE called a '.Context'.  XTCE has a very robust capability to describe different alarms or calibrations in different Contexts.  Close, no change.
2.	Calibration and Alarm Sets.  Calibration and Alarm Sets are used in many ground systems that employ a relational data model.  In actual space systems, calibrations and alarm sets are shared by Parameters when the Parameters of the same 'type'.  For example, all voltage Parameters on a Space System will all have the same calibrations when the same voltage transducer is used throughout the space system - as is usually the case.  Because XTCE parameters are all declared from ParameterTypes, it is very easy to define a single 'VoltageType' with the calibration in the VoltageType and instantiate many Voltage Parameters from the Voltage 'Type'.  Using this declaration technique XTCE offers a very natural means to declare Calibration and Alarm sets once.  

This seems to be a recurring issue and will be addressed in a future ESA Schema change submission.

Ultimate this is an issue of compactness and modularity.  If typical parameter types can be set to one of several calibrations during the lifetime of a mission for example, one would be forced to create a new parameter-type for each one - that is if that calibrator is likely to change a fairly regular basis ( meaning that simply deleting the old information and updating isn't a good solution).  This has the tendency then to explode the type area.  In addition, the sets are a convenient place to group all the Alarms and Calibrators in use by the system.   

MER supports a Union construct because their abstract data types live past decomm.  ASIST also supports the same idea -- that an abstract data type onboard the spacecraft MAY live past decomm.   Although it is possible to let multiple parameters overlap, in a sense allowing for a Union in XTCE.  The issue arises that validating software cannot differentiate this with a bug in a container specification.  A union tag or element of some sort is needed.

Resolution:
ASIST noted that Unions could be 'faked' using the locationInContainer mechanism and at this point doesn't seem to want anything more.  This may not be true in the future however.  The problem with this is deriving unions from the entryLists then, you have to analyze the locationInContainer area and find overlaps,  then one has decide whether the overlapping parameters are unions or just typos. Deferred is fine for now.  

 lack of clean way to describe "system variables", typically flags for tuning of T&C system processing  (JWST, some MER)
 
System specific tunable variables that are not telemetry, often simple boolean switches

Resolution:
For variables that are unique to a particular T&C system, there is no value in capturing them in XTCE, because XTCE is targeted to be an Exchange format.  XTCE authors recommend using a T&C specific data store.  Other items that are operator-set or derived on the ground may be defined as parameters without assigning them to a Container.

lack of clean way to describe multiple documentary type items usually of the form "tag: data" in the text such as:
     SoftwareDeveloper: <your name here>  (JWST+ MER)
 
Compared to these two missions, XTCE seems lean on documentation areas.  Allowing LongDescription to be unbounded and adding a 'name' attribute would help mitigate this issue.

Merged with issue 8875 to provide a more robust documentation capability.

 no tracking mechanism per PARAMETER for changes  (no change log)  (MER + JWST)
 
JWST uses CVS to check-in individual parameter description files, one per telemetry point.   MER uses a change-log mechanism built into the Schema itself, although it does not capture the exact delta between changes. XTCE doesn't preclude the use of the former but doesnt support the latter either.
 

Resolution:
New AncillaryData capability added for issue 8875, supports documentation of changes within a parameter.  Individual parameter storage in a version control system with a merge process or include skeleton is also possible.

MER allows variable length command packet at the TAIL of a packet only.  XTCE seems to support variable length packets at any location and is a super set of this functionality

Resolution:
Not sure what change is requested, since XTCE has a superset of the needed functionality.
Disposition:	Closed

JPL MER schema supports "hardware commands" which are non-CCSDS format commands between or two the low-level onboard hardware

Resolution:
XTCE is capable of defining either CCSDS commands or non-CCSDS commands.  XTCE has been expanded to support additional documentation of named elements per issue 8875.
Disposition:	Duplicate

JWST supports non-CCSDS header commanding similiar to JPL hardware commands in that they are (often) sent between processes or sub-systems onboard (precisely how this works is vague).   XTCE should be able to support non-header command construction easily as it doesn't know anything about headers per se, but this needs to be verified.   However capturing the ROUTING information for the command is not so clear.  In the case of JPL, information is captured as to which software module should process the command (task i believe, although it may be function itself -- kr).  

Resolution:
Capability is covered with changes resulting from issue 8875
Disposition:	Duplicate

XTCE seems to mostly view command issuance from an uplink side, however MER and JWST seems to include mission phase, flight rules, ground rules and command restrictions together before a command may sent.  In addition there is the concept of forbidden commands in MER which means they may never be sent.  JWST has a similiar concept although in each case these forbidden commands may actual be sent somehow.  XTCE may need expansion in this area.

Resolution:
This is related to issue 8908 in that it is simply a nomenclature issue; what is called a mission phase or flight rules or ground rule here (and in many Boeing missions) is in XTCE called a '.Context'.  XTCE has a very robust capability to describe different Command 'Significance' in different Contexts.  Close, no change.
Disposition:	Closed

the documentation on how a proper reference is formed is weak.   As best as I can tell, the text quoted below is the ONLY place the "Unix-style" reference is mentioned in the entire XTCE document under parameterRefType. This annotation only shows up sporadically parameterRefTYpe is often extended or is an attribute.

Resolution:
This is true, and the documentation for references needs to be strengthened both in the schema and in the accompanying documentation.

Revised Text:
Replace:
	<simpleType name="NameReferenceType">
		<annotation>
			<documentation xml:lang="en" >Used when referencing a directory style "NameType".   No characters are prohibited.</documentation>
		</annotation>
		<restriction base="string"/>
	</simpleType>
With:
	<simpleType name="NameReferenceType">
		<annotation>
			<documentation xml:lang="en">Used when referencing a directory style "NameType".   All characters are legal.  All name references use a Unix 'like' name referencing mechanism across the SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage) where the '/', '..' and '.' are used to navigate through the hierarchy.  The use of an unqualified name will search for an item in the current SpaceSystem first, then if none is found, in progressively higher SpaceSystems.  A SpaceSystem is a name space (i.e., a named type declared in MetaCommandData is also declared in TelemetryMetaData - and vice versa).</documentation>
		</annotation>
		<restriction base="string"/>
	</simpleType>

Disposition:	Resolved

 Container/Argument/Stream/Type/etc... -- ALL refs (anything that's a sibling of NameReferenceType?) *should* follow the same format

Resolution:
Merged with issue 8923 (cleanup of parameterRefType documentation)
Disposition:	Duplicate

Clarification is need on Ref names "local" to a spaceSystem and in one area (telemetry/command) vs when crossing "bounderies".  For example, is a simple name sufficient in ParameterEntryRef in the TelemetryMetaData/ContainerSet when refering to a parameter in same TelemetryMetaData/ParameterSet area?   How 'bout when crossing from the command area to the telemetry area?  Certainly when crossing over to another spaceSystem... ?

Resolution:
Merged with issue 8923 (cleanup of parameterRefType documentation)
Disposition:	Duplicate

Ref rules should be spelled out then!  Ex.  Is it legal to ref a container in the command area with one defined in telemetry?  Is it legal to ref a metacommand/commandcontainer in another metacommand/commandcontainer?     Is the RULE really that you add "just enough" path information to fix up name collisions in your document?  OR are we forcing everyone to build all the refs with paths?   What about relative paths?     We should be clear as a bell on all

Resolution:
Merged with issue 8923 (cleanup of parameterRefType documentation)
Disposition:	Duplicate

-- Xpath:  xpath is the XML answer to unix-style paths but includes MATCHING, the ability really to get some chunk of any XML document using an Xpath expression.   We should consider Xpath as the format for Refs... but there needs to be a technical debate.
 
 
"... A reference to a Parameter. Uses Unix ‘like’ naming across the
> SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). To
> reference an individual member of an array use the zero based bracket
> notation commonly used in languages like C, C++, and Java."

sizeInBits is a an attribute in most of the parameterType elements and is an attribute that specifies the HOST SIDE storage length.


  
Further into the decode area there is another sizeInBits which is the "on the wire" size ...


  
Two questions really:


  
1 -- Does it really make sense to specify host storage sizes for a parameter?   It seems to me that this is not important for exchange as long as the host can HOLD parameter,  it doesn't really matter how they do it... (they may not even hold parameters in a standard built-in type in their language but use some other construct)


  
2 -- If the decision is made to keep it, would help to have a slight name change in one vs the other to help clarify its intended use?

Resolution:
sizeInBits has value where the Parameter does not originate from a telemetered source (i.e. it is a derived Parameter or is simply used on the T&C side only).  While the name 'sizeInBits' is duplicative of the Encoding sizeInBits, since their contexts are different, no name change seems necessary. 
Disposition:	Closed

Propose that XCTE ( at this point ) will be limited to exchange and not to all mission data

Ambiguity - The  is too much leeway how to use the standard, and  things are left for interpretation. The standard  allows / calls for users to add thier own  items when they are missing.  Need to tighten the standard so things will be done consistently

USE CCSDS examples how to use the standard ( we can provide  data set with tlm & commnad)

 Too complex, ( I have some examples from the ASIST meeting ).

Should "deramdomization" be de-randomisation" with an 'n' and an 's'?

Contents listing is incomplete - "Foreword", "Introduction" and section "1 Scope" 
	are all missing

Description :	From:    "support of all phases of the satellite"
	To:       "support all phases of the satellite"

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "in all phases of the a spacecraft"
	To:       "in all phases of the spacecraft"
	Resolution:	Fx

Source:	D.Campbell	dave.campbell@scisys
	Description :	Should "deramdomization" be de-randomisation" with an 'n' and an 's'?
	Resolution:	Not sure about the 's'

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "While, the basic"
	To:       "While the basic"

Source:	Makoto Kawai	kawai.makoto@jaxa.jp
	Description :	The annotation of attribute[messageRef] in type[MessageRefType] is to be 
	changed as below. 
	
	From: "name of container" 
	To: "name of message"

Source:	Makoto Kawai	kawai.makoto@jaxa.jp
	Description :	The annotation of type[ContainerSegmentRefEntryType] is to be changed as 
	below. 
	
	From: "An Entry ... order=0" To: "An Entry ... portion of a container. It is assumed

Source:	Amalaye Oyake	amalaye.oyake@jpl.na
	Description :	Future examples should demonstrate onboard EH&A and Event Reporting (EVR) 
	translation to an XTCE compliant XML document. Telemetry contains EH&A and 
	EVR information. This information can be translated into an XTCE compliant 
	document when downlink is complete.
	Resolution:	It is generally agreed that a CCSDS green book (or equivalent) should be written for
	 XTCE, however, no timelime has been established.

Source:	Makoto Kawai	kawai.makoto@jaxa.jp
	Description :	Alarm element is just defined in Integer and Float type in ParameterType, 
	ArgumentType in type[ParameterTypeSetType] and element[ArgumentTypeSet], 
	but all ParameterType and ArgumentType (especially, enumerated type) are to 
	have alarm element.
	Resolution:	Agree, but  implementation of Alarm for non-numeric types needs to be discussed

Source:	D.Campbell	dave.campbell@scisys
	Description :	This should explain how MetaCommand arguments are used compared to 
	Command arguments and how they relate to each other, if at all.
	Resolution:	Clarify text

Source:	D.Campbell	dave.campbell@scisys
	Description :	Lines 2-3. Same query as for DC-013. How is this information used to assemble an
	 uplink / disassemble a downlink? And where are these methods of assembly / 
	disassembly defined? More information in this document or inclusion of a reference
	 to the relevant document would be useful.
	Resolution:	The XTCE powerpoint tutorial contains the best explanatory information on XTCE.   
	Text should be updated to add clarity to the assembly/disassembly mechanisms.

Source:	D.Campbell	dave.campbell@scisys
	Description :	Lines 2-4. Same query as for DC-013 and DC-017. The types listed do NOT 
	contain "the knowledge for how to assemble, disassemble and process spacecraft 
	uplink and downlink streams" - they may hold the constraint or type information 
	required by the assembly / disassembly methods, but they do not define the 
	knowledge of how to do this. There needs to be another document which does 
	Resolution:	Propose revised text 6.1.2.5

Source:	Hans.van.der.Meij	Hans.van.der.Meij@es
	Description :	In a number of places in the schema it is possible to define similar/equal properties
	 of a parameter type. 
	
	E.g. for an IntegerParameterType definition, the sizeInBits and the signed-ness 
	can be be defined as attributes, and it is possible to define this type of information 
	in the IntegerDataEncoding child.
	
	Please clarify which is the preferred way to specify this type of information and 
	what is provided by XTCE to avoid ambiguities and inconsistencies. 
	
	In any case, it is recommended to either update the specification to take out the 
	flagged redundancies or to update the text to clearly define the intended use.
	Resolution:	The document  will be edited to clarify the differences between the two proprieties. 
	The Integer parameter type describes how to handle the parameter in the ground 
	software, while the Encoding integer type describes how the parameter is encoded
	 in either the TM or TC.

Source:	Michael Staub	michael.staub@dlr.de
	Description :	Is command parameter processing intentionally left out? On the other hand, TM 
	calibration is mentioned. The same is valid for command packetization.
	Resolution:	but for command arguments
	Title:	GV-007	Dependencies or aggregation
	Source:	Gert Villemos	gev@terma.com
	Description :	The UML diagrams seems to use dependencies (arrow) instead of aggregation (line
	 with diamond). From the context, aggregation is meant. It is not clear whether the 
	UML diagrams are intended only to illustrate the definition or actually be formal 
	Resolution:	Notation was decided by the tool that was used to do reverse engineering (from 
	XML Schema to UML). It is agreed that the suggested representation is more 
	correct.
	
	ACTION GV-007-01: Gert Villemos to provide updated UML diagrams for XTCE. 
	Due 30May05

MK-007	Don't need element[ChangePerSecondAlarmConditions] 	intype[NumericAlarmConditionType]
	Source:	Makoto Kawai	kawai.makoto@jaxa.jp
	Description :	Currently, element[ChangePerSecondAlarmConditions] is defined in 
	element[ConditionalAlarm] in type[NumericAlarmConditionType], but Change rate 
	evaluation cannot apply to Conditions.  To change as below. 
	
	From: 
	"<element name="ConditionalAlarm"> <annotation> 
	<documentation>…</documentation> </annotation> 
	        <complexType> 
	                <sequence> 
	                        <element name="StaticAlarmConditions" 
	type="xtce:AlarmConditionsType" minOccurs="0"/> 
	                        <element name="ChangePerSecondAlarmConditions" 
	type="xtce:AlarmConditionsType" minOccurs="0"/> 
	                </sequence> 
	        </complexType> 
	</element>" 
	
	To: "
	<element name="ConditionalAlarm"> <annotation> 
	<documentation>…</documentation> </annotation> 
	        <complexType> 
	                <sequence> 
	                        <element name="StaticAlarmConditions" 
	type="xtce:AlarmConditionsType" minOccurs="0"/> 
	                </sequence> 
	        </complexType> 
	</element>"
	Resolution:	To be even clearer, we should change "StaticAlarmConditions" to simply 
	"AlarmConditions".  Fix schema and supporting documentation

Source:	M. Pecchioli	mauro.pecchioli@esa.i
	Description :	It seems that only alarms based on static definition of the allowed value ranges are
	 supported. Spacecraft control systems also require the support of checks against 
	a dynamic reference, either maintained based on commanding activities (this is 
	known as Status Consistency Checks in SCOS-2000) or maintained using 
	telemetry data (this is known as Delta checks in SCOS-2000). Provision for this 
	type of checks (against a 'moving' reference) shall also be made in XTCE.
	Resolution:	XTCE does support a form of Delta Range checks called "ChangePerSecond".  
	Question to RID author: "is this what you are looking for, or are you looking for 
	something else?"  Status consistancy checks should be added to the schema.   It
	 is believed that XTCE does support the RID authors's requirements for Delta 
	checks.
	
	Add clarification for Delta checks.

Source:	D.Campbell	dave.campbell@scisys
	Description :	Lines 8. "All of the encoding information is in the Encoding area." What is this, 
	where is it defined, and why is it not included in the list of terms?
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	Lines 6-7. Same query as for DC-013, DC-017, DC-021. An argument may "include
	 information about how the value is encoded for transmission", but there’s nothing 
	in the document to define how this information should be used. So where is that 
	defined? "All of the encoding information is in the Encoding area." What is this, 
	where is it defined, and why is it not included in the list of terms?
	Resolution:	Text should be updated for clarification

Source:	D.Campbell	dave.campbell@scisys
	Description :	No label or Figure number
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "Figure 3 ParameteTypeSet"
	To:       "Figure 3 ParameterTypeSet"

Source:	D.Campbell	dave.campbell@scisys
	Description :	"CommandMetaDataType" lists its attributes, but the attributes in 
	"TelemetryMetaDataType" are missing.
	Resolution:	Correct UML figure

Footing of Figure 1 is missing.
	Source:	Michael Staub	michael.staub@dlr.de
	Description :
	Resolution:	Add footing

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "user access our confirmations"
	To:       "user access confirmation"
	Resolution:	Fix text - actually should read "user access or confirmations"

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "the organization of the data may be organized hierarchical structure"
	To:       "the data may have a hierarchical structure"
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	Is this a typo?
	From:    "minorFrame 20"
	To:       "minorFrame 8"
	Resolution:	Fix text 6.2.2.3

ource:	D.Campbell	dave.campbell@scisys
	Description :	From:    "the UML refenceces"
	To:         "the UML references"
	Resolution:	Fix Schema annotation and text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "overidden"
	To:       "overridden"
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "a TransmissionContraintList"
	To:         "a TransmissionConstraintList"
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	"MessageSet" is not shown in Figure 1 or Figure 7.
	Resolution:	 Figure 7 does not show a MessageSet because it is not part of 
	CommandMetaData (whether it should be is another discussion).

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "RF hardware and other many other assets"
	To:       "RF hardware and many other assets"
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "The collection of messages to search thru"
	To:       "The collection of messages to search through"
	Resolution:	Fx text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "a Parameter it is not the value itself."
	To:       "a Parameter is not the value itself."
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "is is possible"
	To:       "it is possible"
	Resolution:	Fix

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "Most Parameters, are"
	To:       "Most Parameters are"
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "Most Arguments, are"
	To:       "Most Arguments are"
	Resolution:	Fx text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "markup documentation,"
	To:       "markup documentation)"
	Resolution:	Fix text

Source:	D.Campbell	dave.campbell@scisys
	Description :	From:    "Element and Type names begin with a capitol letter."
	To:       "Element and Type names begin with a capital letter."
	Resolution:	Fix text and associated schema annotation

ource:	M. Pecchioli	mauro.pecchioli@esa.i
	Description :	It seems that logarithmic calibrations are not supported by the 

standard. I think 
	this should be added.
	
	-----Added after meeting with clarification by MP of 18Apr05:
	
	What we support in S2K is the following:
	
	In the case of parameters associated to a logarithmmic calibration, the engineering
	 value ‘Y’ corresponding to the raw value ‘X’ of a parameter is calculated using 

the 
	following formula:
	Y = 1 / [A0 + A1*ln(X) + A2*ln2(X) + A3*ln3(X) + A4*ln4(X)]
	Resolution:	Question: Would a polynomial approximation be close enough?  What 

forms of 
	logarithmic calibration are required: natural, base 10 other.  What direction of 
	conversions are required?
	
	Discussion: what is ln2 (a base 2 log or the second natural log?)

Source:	Michael Staub	michael.staub@dlr.de
	Description :	Reword: "The space industry is fragmented between Packet telemetry 

and 
	commanding and Time Division Multiplexing (TDM) telemetry and commanding."
	Resolution:
	Title:	MS-001	Missing page numbering
	Source:	Michael Staub	michael.staub@dlr.de
	Description :	Add page numbering to document.

Source:	Michael Staub	michael.staub@dlr.de
	Description :	Add page numbering to document.

ource:	D.Campbell	dave.campbell@scisys
	Description :	Lines 5-7. What is the information which states how encoding should 

be 
	performed? The text mentions the "Encoding area" - where / what is this? What 
	constraints are there / what documents specify how the encoding is to be 
	performed? Should this information be included in this standards document? 
	Different agencies may misinterpret how to use the encoding information unless its
	 use is also standardised in some document.
	Resolution:	Add clarifications to the text

Source:	Gert Villemos	gev@terma.com
	Description :	The schema file should be clearly identifiable, i.e. the XTCE 

document version 
	referenced and/or the schema file version number changed.
	Resolution:	Add version number to document

Description :	Currently, element[ContextCalibrator] in element

[ContextCalibratorList] in 
	type[IntegerDataEncodingType], [FloatDataEncodingType] and 
	[StringDataEncodingType] are defined by complexContent. To make the structure 
	more simple, I recommend to use type[ContextCalibratorType] in 
	type[IntegerDataEncodingType], [FloatDataEncodingType] and 
	[StringDataEncodingType]. 
	
	From: "<element name="ContextCalibrator" maxOccurs="unbounded"> ... 
	</element>" To:   "<element name="ContextCalibrator" 
	type="xtce:ContextCalibratorType" maxOccurs="unbounded"/>"
	Resolution:	Good input.  Fix schema and associated documentation.

Source:	Makoto Kawai	kawai.makoto@jaxa.jp
	Description :	Currently, the definition of element[SyncStrategy] in type

[FixedFrameStreamType] 
	is described by complexContent.  To make the structure more simple, I 
	recommend to use type[FixedFrameSyncStrategyType] in 
	type[FixedFrameStreamType]. 
	
	From: "<element name="SyncStrategy"> ... </element>" To:   "<element 
	Resolution:	Agree (with discussion).  Suggest instead simply deleting 
	FixedFrameSyncStrategyType (since it is would be used at most once).

Source:	Thomas Huang	txh@mipl.jpl.nasa.gov
	Description :	There are a few minor cosmetic  errors 
	In the Green Book - Page 15 - <TAG>data<\TAG> should be <TAG>data</TAG> -
	 Page 22 - missing '/' before SpaceSystemV1.0.xsd in xsi:schemaLocation - Page 
	36 - same problem as in Page 22. 
	
	In the Red Book - Page 13 references 'Appendix A'.  I think it should be 'Annex A'. 
	- Page 24 - sub-heading 6.1.3.2.6 used twice (for Interlock and Verifiers) - Page 

25 
	- perhaps a page and/or section break before '6.2 The Schema'. - Page 70 - 
	perhaps a page/or section break before 'Annex B'.

ource:	M. Pecchioli	mauro.pecchioli@esa.i
	Description :	There are many specific (and non-obvious) terms used in this 

standard. They 
	should be introduced and explained clearly in Section 4. Unfortunately, in the 
	current version of the standard, only the obvious terms (telemetering and 
	command) are defined. In the state where it is, the standard cannot be really 
	understood and thus reviewed without a very significant effort.
	Resolution:	CLARIFICATION  Add additional terms

ource:	Makoto Kawai	kawai.makoto@jaxa.jp
	Description :	Type of element[MessageRef] in element[MessageRefSet] in type

[ServiceType] is 
	undefined.  
	
	To change as below. 
	
	From: "
	<element name="MessageRef" maxOccurs="unbounded"/>" 
	
	To: "
	<element name="MessageRef" type="xtce:MessageRefType" 
	maxOccurs="unbounded"/>"

Source:	Mario Merri	Mario.Merri@esa.int
	Description :	In an ideal world, the Project Manager of a new space mission would 

like to have a
	 simple life and put a single requirement to the Spacecraft Prime Contractor that 
	reads something like: "It shall be possible to export the operational database into 
	XTCE (ref. .)".
	
	To have project managers buying in XTCE, we should be able to demonstrate the 
	goodness of the requirement above and explain that the Prime Contractor will have 
	to produce a simple tool to translate from their internal DB format into XTCE. 
	Therefore, the questions are: 
	
	a) are the XTCE specifications enough to unambiguosly develop the software tool 
	that translates into XTCE?
	
	b) Where should a new mission start from? (missions tend to re-use what has 
	been done by other mission before. In the absece of a predecessor is there any 
	help that we coulf provide to missions?)
	
	Clarification and possibly real-mission examples should be provided to clarify the 
	above.
	Resolution:	Update introductory section and consider development of associated 

tools (e.g. 
	validator).

CNES remarks and recommendations for the XTCE norm CNES (French Space Agency) has led a study to determine if and how the XTCE standard can be used in the context of the Myriade project. (Myriade is a microsatellites family, initiated by Demeter, Parasol …). Some files produced by the actual Myriade data base (called BDMS)for the CCC Control Center have been translated in XTCE. Here are the results of this study : About Telemetry : We have chosen the decommutation plan which is one of the most representative file among those who are exported from the system data base. In this file we have chosen a significant TM packet (called ECU) with a structure containing a discriminating element (part of the telemetry depends on the value of a parameter called a "selector"). The complexity is to separate the data from the processes in the BDMS to define the best implementation with theXTCE norm. We see that the data in the XTCE file must be processed in order to obtain the expected file (addition of ground calculated parameters, renaming of some parameters, calculation of the offset, ...). For the XTCE norm itself, we can notice that there are two ways to define conditional structure. We think that, at least, a way to use XTCE must be recommended in order to obtain a homogenous implementation in different projects. About Telecommands We encountered some difficulties in trying to implement the example of TC with the XTCE norm. We found a lot of similarities in the definitions of types included in the TelemetryMetaDataType and the CommandMetaDataType elements. In some cases, these similarities present slight differences, which are obviously not enough justified with sufficient explanations (ie the definition of the CommandContainer is different coming from CommandMetaData/MetaCommandSet/MetaCommand or coming from CommandMetaData/CommandContainerSet), and therefore resulted in some confusions. The structure of nested types is not easy to assimilate. Some information seem to be redundant inside a type. It would be useful to have more explanations of this case. At first, the information provided by the TC example and the elements defined in the XTCE norm didn’t fit. We finally carried out a way to proceed, nevertheless, there is no evidence that our solution is the best one. The point that is not resolved is how to implement the variable argument. Conclusion of the study Within the framework of this study, the scope of TM/TC implemented with XTCE clearly appeared as limited. We focused our study on a subset of one TM packet, and also on one specific TC. As a result, the first step can be consider positive. However, in the absence of a more exhaustive study which encompass more possibilities of XTCE, the overall feasibility is still pending. The most important problem of the norm is that it is very complex, and difficult to learn, even for engineers experimented in XML, and data base schemas. Its complexity comes from its genericity. We think that there are too many ways to define a TM packet with this norm to be sure that every project will define its telemetry using the same philosophy. In the SpaceSystem schema which describes the norm, the <Annotation> sections are very succinct and sometimes not sufficient. So, in order to help users to understand the schema, the chapter 6 (The Specification) of the XTCE norm should contains more in-depth explanations. Moreover, the standard is far from being user friendly due to excessive offered possibilities in terms of implementation. We did not find any example corresponding to our needs. The available documentation is surely not designed for an easy learning. Of course, a tutorial is to be issued. A solution to reduce the learning effort could be to define a smaller kernel of the norm, with some possible extensions for some specific use. One important lack of the norm seems to be that it does not enable a user to define its own tags and attributes in order to complete the description. This could be the solution to avoid changing the norm each time a particular need appears in a project. Another important remark we have to make is about the state of XTCE. The norm has changed a lot between the OMG version of 2004 and the referenced CCSDS red book. It seems not to be still defintly defined. This fact is very important because if we want to use the norm in an operational context, with have to be sure that there will not have big changes before starting the development of tools based upon the norm. Tools are mandatory to use this norm because it is quite impossible to create a full XTCE file with a simple XML editor. When the norm will be approved, the XML-oriented database can be the next step in the XTCE deployment. It could be interesting to have a generic code that enables the updates of a database by reading a XTCE file and enables the extractions from a database to produce some XTCE files. Xavier Passot CNES DCT/SB/CC With Erwann Poupart (CNES DCT/PS) and Frederic Berriri (CS/SI) 

Textual calibrations are not represented as calibrators. It would be interesting to put the textual  calibrator in the same set as spline calibrator. Actually, the textual calibration is represented  by a ToString element. At least this element should have a name, a short description attribute such that there will still be a  possibility to recover original names. The best solution would be to integrate ToString element, enhanced with name and short description attributes, to the  normal set of calibrators. 

Resolution:
This is related to separate calibration and alarm sets. A schema change will be submitted by ESA on another issue.
Disposition:	Duplicate

Spline calibrators and polynomial calibrators, as well as all other calibrators should have a short description attribute for documentation and human readable information storage. A name attribute would allow to keep original calibrator ids during conversion

Calibrators (either text, polynomial or spline) may be reused between parameters, and they 
always have to be defined in relation to a parameter type. This may imply copy paste work during conversions. It should be easier and clearer to define calibrators in a separated set, at  the telemetry or/and command level, and to references them when needed. This solution would  have the avantage to shorten the length of the XTCE file, and avoid copy past of similar contents. 

Resolution:
Duplicate of issue 8908, part of that issue is deferred.
Disposition: Duplicate

In SCOS 2000, a calibrated value has an engineering format and a radix attached to itself. 
        These concepts are not supported by XTCE. For a proper conversion it is interesting to have an engineeringFormat attribute, and a rawRadix attribute. The engineering format can be signed/unsigned integer or real. The radix is only applicable to unsigned integer parameter value and can be decimal, hexadecimal or octal. 

Resolution:
Unsigned integer values are allowed to be prefixed with 0x or 0o in order to indicate a hexadecimal or octal value, respectively.  The assumed radix is decimal.
Disposition: Closed

Boolean parameter can have a textual calibration in XTCE. For Boolean there is no ToString 
element but two attributes: oneStringValue and zeroStringValue. Even if this solution is 
acceptable it contradicts other textual calibrations (ToString elements) and cause problems for conversions. It is absolutely necessary to have these two attributes? Would not it be possible to use the ToString element for Boolean parameters?  Moreover, for boolean parameters, the unit set is always empty it does not have any sense (a boolean can only be a flag..). 

Resolution:
Issue is a duplicate of 10174 which is deferred.
Disposition: Duplicate

SCOS 2K uses another type of calibrators that is not supported by XTCE. XTCE should provide a way to support a kind of logarithmic (or custom) calibrator. The calibration is defined by the following equation: Y = 1/{A0 + A1 ln(x) + A2 ln2(x) + A3 ln3(x) + A4 ln4(x)}. Ln is the natural log (base e), and Ai are coefficients stored for the calibrations. Of course such a 
calibrator will need, as others, a short description and a name. If this thought as not generic 
enough, then XTCE should give a way to describe non standard calibrators. For example, coefficient, base, exponent in a term sum used as a calibrator. 

Resolution:
Submit potential new calibrator as a Schema modification
Disposition: Deferred

Alarms in XTCE are only available for parameters of type integer or float. In SCOS 2K, alarms 
are defined for any type of parameter. Moreover alarms in S2K can be of several types: soft  limit - hard limit- delta check - status consistency (linke to relevant telemetry parameter) - event generation - or application specific. For this reason a attribute or element describing the  type of the alarm (proprietary list or constrained value list) would be the best. 

Resolution:
Alarms have been defined for all parameter-types in telemetry.  
Revised Text:
Changes were affected by Validity issue 10185 and are shown in that section.
Disposition: Resolved

A fixed value cannot be added to a container created in the ContainerSet but only to a 
container created in the MetaCommand object. In SCOS 2K, fixed values would be added in 
the Meta Command and this cannot be done. Add the Fixed Area support to container defined   with the MetaCommand would help

Resolution:
Please expand upon the problem described.   The element FixedValueEntry is available in the MetaCommand/ CommandContainer/EntryList but not in the CommandContainerSet.
One possible workaround would be to carefully "divide" a container between metacommand and command container.  In other words given a container that consists of 11 parameters, let the 6th one be fixed.  Simply create two containers,  the 1st contains the first 5 parameters.  This would be ref'd in MetaCommand area.  Then define the 6th FIXED value, and finally Ref the 2nd set of parameters in 2nd container in the metacommand entry list.

A TC & TM database may contain specific information about telecommands. In particular, the source of the telecommand can be indicated (like if it has been produced by a planning  software or smth else). 
        
SCOS has a flag to say if the current command can be executed alone, manually, or only as 
part of a command sequence. This flag cannot be translated in XTCE. 
The priority of the command cannot be represented (only the criticality). This is a new potential attribute for the metacommand element

Resolution:
This sort of "flag" information is very specific to particular implemenations and as such no clear way is given in XTCE to handle it.  The preferred way at this time is to hold that information in a system unique document, or in a system unique way in XTCE.  In either case, that type of information must be documented before given to another party.  Duplicate of 8910 which was closed with no changes.
Disposition: Duplicate

It is possible to set a default value (i.e. initial value) for a command parameter in XTCE, but in SCOS 2K, the default value is sometime expressed in the engineering format. And XTCE 
does not support the engineering format for the default value. XTCE should allow default value  in engineering (calibrated) format and give a way to deduce the format of the default value

Resolution:
Add Boolean flag to determine if initialValue is calibrated or not.  Add "typeless" initialValue to parameter so initialValue can be stored as String.  ESA submitting proposed Schema change

Command verifiers should have name and short attributes if possible. They could even be 
defined in a set, and integrated into a command through the use of references (this would even be faster and shorten the length of XTCE, and improve XTCE reuse as well). Those fields are needed because in SCOS 2K verifiers are labelled with a description and an id (ie. Name). 

Resolution:
CommandVerifierType was changed to be an extension of the OptionalNameDescriptionType so that it would allow an optional name and short description.

SCOS 2K allows tolerance (range check) during the command verification check. The tolerance check is not supported by XTCE. Basically a plus/minus value added to the value to be checked is the tolerance valid range. This can be represented in XTCE either by a valid range (that exists already for other elements, with min and max values) or by a unique attribute (tolerance) that will be added or deduced to/from the value to check. 

Resolution:
CustomAlgorithm and CheckWindow elements were added to the CommandVerifierType

XTCE allows a single valid vange for argument value. SCOS 2K allows multiple valid ranges 
for argument values and these cannot be represented in XTCE. For example, if there are two discrete ranges for the argument then XTCE fails to represent this. 
 Moreover in SCOS, range set are caracterized by a name, a short description, a flag 
identifying the expression used (calibrated or not), a radix (flag identifying the radix used for the range values specified in value list, applicable for unsigned integer values, can be decimal - hexadecimal or octal) 

Resolution:
ValidRangeSet added.  

The parameter unit in XTCE is attached to the parameter type. In SCOS, it is not easily 
possible to define them here and it would be easier to place the unit in the parameter definition (because SCOS uses PUS based parameter types). With the unit in the parameter properties, the parameter type set will be shorter, and would then describe only PUS parameter types for example. Actually there is one parameter type per parameter instance, which is not ideal

Resolution:
Duplicate of issue 10153.
Disposition:	Duplicate

It would be great to define PUS (C-Telemetry and telecommand packet utilization, ECSS-E-70- 41A, 30 Jan 2003, chapter 23 ) parameter types and then extends these types for the need of the database. This means that there should be a way to derive parameter types, or extend  them (the same concept exists already for containers). With this extension, the parameter type set would be much smaller than now and simpler to understand. 
A way to provide this is to add an attribute to a parameter type that allows to reference another parameter type. 

Resolution:
Added "baseType" to allow inheritance mechanism of types

In the schema it is not very clear where to add the algorithm used to compute derived 
parameters. As the derived attribute is set in parameter properties, the only place to add the  algorithm is under this element. But the only reference or implementation of an algorithm in the  parameter properties is under validity condition/ custom algorithm which is not really the best  place. Has the derived algorithm been forgotten by the author or where is it? In relation to SCOS this is where the content of synthetic parameter is copied (the expression for the 
derivation). 

Resolution:
Definition of a schema for complex derivation algorithms was intentionally left out of the XTCE specification.  It is possible to use a simple algorithm (arithmetic combination of two parameters) or reference a named algorithm that is externally defined.

A spelling mistake must be corrected in the Argument Definition. It concerns ArgumentArrayType (and is actually ArgumementArrayType). 

Resolution:
ArgumentArrayType is now spelled correctly

When building a command, SCOS has a second possiblity to set default values. Default 
values cannot be set while the command is being built (in the entry list). SCOS supports the 
following at this stage: the default value, the type of the default value (calibrated or not). 
        
Dynamic default values (through telemetry parameters look up) are also possible in SCOS,  but cannot be represented in XTCE. To do this, a reference to a TM parameter should exist for  the command argument

Resolution:
Added initialValue override for Parameter and Argument.

Block meta command, namely command sequences support, is not satisfactory for SCOS  ASCII MIB. There is not enough details, and sequences cannot be described in XTCE. 

Resolution:
Duplicate of issue 10186 which is closed without change.  Command sequences (beyond simple sequences that can be defined within a container) are to be considered by other specifications.
Disposition:		Duplicate

At present there is no entry type available to define the complementary or redundant data. I.e.  TM parameter Battery1TempA has redundancy parameter Battery1TempB, and TC 
Battery1Disconnect has complementary TC Battery1Connect. 
 For Telecommands and Telemetry Parameters & Packets a list should be added where can be added the names of the redundant or complementary data related to that data. A list is needed as there might be multiple entrys of each. 

Resolution:
Duplicate of 10169 which is deferred due to complexity.
Disposition: Duplicate

Defining the model type to which space elements are applicable, i.e. SVF, EM, PFM, etc are 
not available. 
 For each system element include a list where the models for which this system element are 
valid are include. All elements of that system element are then valid for all the models in the 
list (Engineering model, thermal model, flight model, system verification facility, etc). 

Resolution:
Duplicate of issue 10162 which is resolved.
Disposition:	Duplicate

:        Aliases do not seem to inherit through the space-system elements like names, i.e. 
        Sat1/power/bat1/voltage may have alias of 012 within the bat1 alias set and should have 
        something like S1PB1012 within the system alias set, so that it is unique within the subsystem 
         and whole system? 
        
        Aliases may inherit names through the space system elements, however for this to happen 
        the alias for each system element needs to be available. So an alias entry needs to be 
        provided for each system-element unique in its hierachical position. I.e. B1 for battery1, P for 
        Power, etc. This could be an alias list at each space system element. 

Resolution:
There are intentionally no restrictions on alias naming.  Enforcement of a particular alias naming scheme however is system dependent and not related to definition exchange other than the documentation of the naming scheme which is allowed in the SpaceSystem definition.

There are no specific descriptions of onboard memory possible, i.e. block size, addressing technique, etc as per tables 12, 13 of the ECSS. This I would expect at the space-system 
description level? 
        
Onboard memory is a very specific type of space system element, for which a lot of specific data is always needed, and it would be worth making specific entry types appropriate to  onboard memory system elements. This to include Memory ID, Accessibility (read,write), smallest addressable unit, addressing technique, block length, subblock symbolic name, subblock offset, subblock length, etc

Resolution:
Onboard memory handling between different spacecraft and ground systems has been even more varied than commands and telemetry.  To the extent that onboard memory locations can be named and brought down as "software telemetry" they are supported by XTCE, however, an exchange format for memory definitions beyond telemetry parameter definition is out of the current scope.  It is possible that this could be addressed by a future specification, but there are also numerous specifications for memory data for ordinary ground-based computer systems (Motorola S-records, Intel Hex format, Unix STABs, etc.) that may be applicable.
deferred

The are no OBSW space element, specific additional information such as OBSW version, 
memory that is read, write, unreadable, protected, constant, variable, start address, etc. 
        
This may be out of scope of XTCE, but another very common database exchange on modern 
 missions. OBSW memory map and execution information, which should ideally be included as a very specific space system element. And is the OBSW version that is valid for the database release. 

Resolution:
AncillaryData may provide enough flexibility to hold some FSW information.  However it will be system unique and should be used with care.  Otherwise, FSW info is out of the intial scope of XTCE (command & telemetry) and would require new revisions and probably a new RFP from the OMG to address it. 
Disposition: Deferred

Aliases, Long Description and Short Description are not available with all major data types, i.e. Calibration curve. 
        
For consistency all the important data types should be able to have alias, long description and short description associated to them, even if they are not all necessarily populated. 
Depending upon the database providers so rather than others will be populated

Resolution:
The NameDescriptionType (see issue 9200) has been included in almost all the major elements.  If any are missing, they need to be added.  This type is now in Calibrator for example.  Any other areas should be submitted with proposed Schema change.

Schema Change in XTCE 1.1:  initialValue of type "string" created in ParameterSet area, overrides ParameterType area, format flexible for ParameterType.

Resolution:
initialValue of type "string" created in ParameterSet area, overrides an initialValue supplied in the ParameterType area, format flexible for ParameterType. 

2 - Expand explanatory material on the differences between Telemetry and Command Parameters in XTCE (ESA-032)

Non-normative portion of XTCE 1.1 specification extended

Resolution: 
Non-normative portion of XTCE 1.1 specifications extended

3 - Expand explanatory material related to "Figure 2" in the non-normative part of the XTCE specification (ESA-039)

Extended in XTCE 1.1

Resolution: 
Explanatory non-normative text extended in XTCE 1.1

4 -- Expand explanatory material related to "Figure 4" in the non-normative part of the XTCE specification (ESA-041)

Expanded in XTCE 1.1

Resolution: 
Explanatory non-normative text extended in XTCE 1.1

5 -- Expand explanatory material related to "Figure 6" in the non-normative part of the XTCE specification (ESA-053)

Expanded in XTCE 1.1

Resolution: 
Explanatory non-normative text extended in XTCE 1.1

6 - Add Delta Alarms to XTCE (ESA-016)

Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area

Resolution:  
Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area
add the following type of alarm;  
	delta-check alarm with the following data:
	* Validity condition (to know if the test is applicable)
	* The delta threshold (raw or calibrated value of the threshold)
	* An indication to say if this is a minimum or a maximum delta check (attribute)
	* As required in JM-013, a label to indicate the activity triggered by a positive alarm

7 - Expand explanatory material related to "Figure 2" in the non-normative part of the XTCE specification (ESA-034)

Extended in XTCE 1.1, this is similar to ESA-039

Resolution: 
Figure replaced and section names match class names

8 - Expand explanatory material related to "Figure 3" in the non-normative part of the XTCE specification (ESA-040)

Expanded in XTCE 1.1

Resolution:
Figure replaced, additional explanations added with revised text in issues 10250, 10251, 10255, 10256, & 10260.

9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type, in the XTCE specification (ESA-045)

Extended in XTCE 1.1

Resolution: 
Explanatory text extended in XTCE 1.1

10 - Add indicator of operational status to XTCE (JPL-004)

Not completed

Resolution:
A tag will be added at the space system level, to identify the current operational status

1 - Change service set to either accept Messages or Container references (ESA-004)

Schema changed in XTCE 1.1

Resolution:
Schema changed in XTCE 1.1
Change the cardinality of the containerrefset in services

2 - Add Aggregate (similar to C-structure) type to XTCE (ESA-014)

Schema support added in XTCE 1.1, see AggregrateType in ParameterType area

Resolution:
proposed AggregateParameterType with XML example has been created.  

3 - Expand explanatory material for XTCE types ParameterToSet and MetaCommand/Verifiers (ESA-071)

Expanded in XTCE 1.1

Resolution:
Agree, greater elaboration could be useful.   The Parameters should be set to new values in the order presented (to ensure any triggers are executed appropriately). The RID is accepted, and changes will be done shortly.

4 -- Add a name/short description to the argument's valid range set (ESA-011)

Added OptionalNameDescriptionType to support this in XTCE 1.1

Resolution:
Will make this an OptionalNameDescriptionType.Schema changed in XTCE 1.1

5 - Expand explanatory material in Figure 1 (ESA-026)

Expanded in XTCE 1.1

Resolution:
Telemetry streams and command streams are shown and captioned.

6 - Figures 2-10 not referenced in text (INPE-009)

References inserted in XTCE 1.1

Resolution:
Text Revised for Figures 4 & 5.  All figures appear in a section related by name to the figure.

1 - Support ability to describe redundant or complimentary data (ESA-001)

Defer (complexity)

Resolution:
A true general relationship description could become very complex.  This is deferred

2 - Add separate CalibratorSet to XTCE as many legacy system hold calibrators in tables (ESA-006)

Defer (breaks current XTCE model, complexity)

Resolution:
Although the issue is identified. No satisfactory solution could be found to resolve the problem. This 	has been deferred to a further release

3 - Use UML Instance diagrams for XTCE document example (ESA-038)

Defer (more appropriate for XTCE CCSDS Green/Magenta Books, future work area)

Resolution:
This topic has been deferred to a future release

4 - Separate XTCE Schema into constituent parts (JPL-016,022,026,030)

Defer (possible future work area

Resolution:
Originally XTCE started this way, then merged to allow for unification of concepts, and types, and because of better XML tool support for combined documents.  It may be time to split it apart again but this is a large task, and is deferred.

5 - Align XTCE and CCSDS Navigation Schemas (types) (JPL-029)
 
Defer (possible future work area)

Resolution:
SIG group at CCSDS is working on this topic. As the schema produced by the Navigation Working Groups is less mature than XTCE, the coordination will be done later (not relevant now..).
Revised Text:
Disposition:  Deferred

6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types (ESA-007)

Defer (no agreement on approach)

Resolution:
No agreement on how to proceed among active members
Revised Text:
Disposition:  Deferred

7 - Use UUIDs instead of current XTCE Referencing mechanism (ESA-005)

Defer (complexity, no agreement on approach, further consideration needed)

Resolution:
In order to allow multiple XTCE SpaceSystems to be developed independently and combined without namespace collision concern, use the hierarchical XTCE structure.  UUID creation would require a master UUID authority to ensure uniqueness.    
Revised Text:
Disposition:  Deferred

8 - Add activity field to Alarms to indicate what the alarm will trigger (ESA-015)

Defer (further discussion needed)

Resolution:
This field is more appropriate for linkage to procedures rather than associated with the command and telemetry definitions.  Future specifications may appropriately address linkage or system responses to alarms and system events, e.g. SOLM.  ESA & NASA agreed to defer.
Revised Text:
Disposition:  Deferred

9 - Add filtering of value threshold to maintain telemetry at certain rates (ESA-048)

Defer (additional discussion, future work area)

Resolution:
This idea is good, but the clarifications came too late for an implementation. Defer to future release.
Revised Text:
Disposition:  Deferred

Summary of Non-RID Requests

1 - Add ability to describe general equations in Calibrator area

General MathOperationCalibrator added to Calibration area, MathOperationType changed to support equations, effects other areas of schema where "MathOperation"s are used

Resolution:
General MathOperationCalibrator added to Calibration area, MathOperationType changed to support equations, effects other areas of schema where "MathOperation"s are used.

Summary of Close RIDs
NASA-013: The non normative document (accompanying text) must stipulate the following: The use of XTCE is advocated as being appropriate for data exchange across organizational or product  boundaries, but is not required to be adopted as a recommended practice for the internal technical specification of command or telemetry data dictionaries or data streams within a particular system or product
RID RESPONSE:
The OMG cannot mandate the use of any specification - all OMG specifications are recommendations.
We suggest that this language be place in the XTCE Green book or Magenta book.
RID STATE:	CLOSE

Resolution:
The OMG cannot mandate the use of any specification - all OMG specifications are recommendations We suggest that this language be place in the CCSDS XTCE Green book or Magenta book.
Close

For each system element include a list where  the models for which this system element are valid are  include. All elements of that system element are then valid for all the models  in the list (Engineering model, thermal model, flight  model, system verification facility, etc). These models relate to the various developments of the final satellite. The Flight model is the complete satellite ready for launch, however there will be a number of engineering models, development models, breadboards and test facilities that are also built and tested during the satellite development and require a database exchange. These databases can be sent individually in a self contained database, or can be sent combined in a mission database which therefore needs the means to differentiate between what is valid for what model. This is further complicated with onboard software versioning which can also be included in the model list.
RID RESPONSE:
Recommend simply using SpaceSystem name attribute or XML file name to separate models.  
According to another RID, a tag will be added at the space system level for the operational level of the 
system (testing, operational, etc..)
RID STATE:	CLOSE

Resolution:
Recommend simply using SpaceSystem name attribute or XML file name to separate models.  According to another RID, a tag will be added at the space system level for the operational level of the system (testing, operational, etc.., issue 10162) 
Close

In SCOS-2000 calibrations curves are allowed to be described by one point only. In XTCE, a spline is 
obviously defined by two points miminum. Please relax the constraint to two points
RID RESPONSE:
[ESA] close, withdraw
Boston: agree close
RID STATE:	CLOSE

Resolution:
Closed, withdrawn after discussion with ESA at Boston meeting.

The MAP ID is situated in the segment (packet application data field). In ECSS there is a need for associating a label to the value of the MAP ID, describing the priority of it. In XTCE while describing a container, which could include the parameter MAP ID there is only the possiblity to include the value of the MAP itself (1-64). We would like to add the label high priority, low priority with the 
MAP ID.
In ECSS, there is a list of MAP id associated to APID, with default MAP for such a process. This data can be recovered from browsing through all containers and extracting apid, map id values. But maybe a simpler way must exist?
Jennifer/Kevin/Gerry-reviewd, agree
Gerry recommends using AncillaryData.  Close/No-change.
Boston: close
RID STATE:	CLOSE

Resolution:
Closed, withdrawn after discussion with ESA at Boston meeting.

ECSS E70-31 has dedicated table to create generic commands. In particular for CPDU, On/off devices, register loads and sensors data. Although dedicated commands could be written down as a whole, they may be sufficiently generic to be included in XTCE. From another point of view, with a good reuse of command structure, such commands can be easily formatted in XTCE. However some defaults values like cpdu duration units and cpdu max instr will have to fit somewhere. The best place would be at the space system default level (currently this kind of information could only fit in the space system ancillary data set.).
RID RESPONSE:
Discuss.  Recommend  creating a base command from which specific commands are inherited.
[ESA] ok with Gerry response
Jennifer/Kevin/Gerry-reviewed, agree
Boston: close

Resolution:
Closed, withdrawn after discussion with ESA at Boston meeting.

DESCRIPTION OF REQUESTED CHANGE
It is from our side believed that delta-check alarms and expected state check alarms are sufficiently generic and well spread to be included in XTCE.  Therefore we ask to add the following type of alarm;  expected check alarm with the following data:
·	Validity condition (to know if the test is applicable)
·	A list of expected values
·	As required in JM-013, a label to indicate the activity triggered by a positive alarm
	
[Ian] can you check is that can match to the ParameterToSetList in the MetaCommand element. What is missing for me is the reporting data referenced (namely where to find the parameter name to be setted by the telecommand). If this does the job then no RID to be raised.
RID RESPONSE:
[ESA] on ESA side, this is covered by StaticAlarmRange
RID STATE:	CLOSE

Resolution:
Closed after discussion at Boston meeting, this is covered by StaticAlarmRange.

DESCRIPTION OF REQUESTED CHANGE
As a valid range set has been introduced instead of one unique range, it is now needed to have a validity condition that tells if the current range is applicable or not.
RID RESPONSE:
Conceivably, valid range could change with context, however, this seems obscure enough that the RTF 
should consider whether the additional schema complexity is worth the cost.  Recommend Deferral.
[ESA] withdraw, this is being addressed
Boston: close
RID STATE:	CLOSE

Resolution:
Closed after discussion at Boston meeting

The support of command sequences is not satifactory for ESA, and ESA would like to have command sequences in XTCE. Is there any work ongoing on that side for XTCE, or is it intended to leave complicated command sequences (Block Meta Command) out of XTCE. ESA could propose a model for the command sequence support.
RID RESPONSE:
Yes,  in fact the OMG/SDTF is currently reviewing a proposed specification for a very robust command sequence model.   This model would augment XTCE.   Recommend closure.
Status: reviewd and closed
Type: Schema Change
	
Boston.  No changes to XTCE.
RID STATE:	CLOSE

Resolution:
Yes,  in fact the OMG/SDTF is currently reviewing a proposed specification for a very robust command sequence model.   This model would augment XTCE but is a separate specification.   Closed after discussion at Boston.

DESCRIPTION OF REQUESTED CHANGE
An analysis is on-going for two satellites database (Metop and Herschel-Planck) and more RIDs are expected in the next weeks.
RID RESPONSE:
Status:  comment, Closed
Boston: close
RID STATE:	CLOSE

Resolution:
Not an issue with the XTCE specification

DESCRIPTION OF REQUESTED CHANGE
Change "Interface design to satellite systems" to "Ground interface design to satellite systems"
RID RESPONSE:
Recommend not changing as telemetric and command processing DO NOT have to be performed on 
the ground.
RID STATE:	CLOSE

Resolution:
Recommend not changing as telemetric and command processing DO NOT have to be performed on the ground.
Close

DESCRIPTION OF REQUESTED CHANGE
Change "XTCE provides a standard format for defining the Telemetric and Telecommand (TM/TC) data required to perform the processing shown in figure 1." to  "XTCE provides a standard format for defining the Telemetric and Telecommand (TM/TC) data required to perform the ground processing shown in Figure 1."
RID RESPONSE:
While the processing depicted  is normally accomplished on the ground, it does not have to be - consider a space station controlling another space asset. 
Recommend not changing as telemetric and command processing DO NOT have to be performed on 
the ground.
RID STATE:	CLOSE

Resolution:
While the processing depicted is normally accomplished on the ground, it does not have to be - Closed

DESCRIPTION OF REQUESTED CHANGE
Change caption from "Telemetric and Command Processing Meta Data Encapsulated in XTCE XML" to "Telemetric and Command Ground Processing Meta Data Encapsulated in XTCE XML"
RID RESPONSE:
See remark in ESA-23
Recommend not changing as telemetric and command processing DO NOT have to be performed on 
the ground.
RID STATE:	CLOSE

Resolution:
Recommend not changing as telemetric and command processing DO NOT have to be performed on the ground.
Close

DESCRIPTION OF REQUESTED CHANGE
Include AlarmLimitSet
RID RESPONSE:
Covered by the magenta book.
RID STATE:	CLOSE

Resolution:
Recommended practice that is covered by the magenta book.
Closed

DESCRIPTION OF REQUESTED CHANGE
Correct inconsistencies between StreamSetType in Figures 3 and 6.
RID RESPONSE:
We believe they do match.  Figure 6 simply has its aggregation shown as separate classes rather than attributes.
RID STATE:	CLOSE

Resolution:
We believe they do match.  Figure 6 simply has its aggregation shown as separate classes rather than attributes.
Close

DESCRIPTION OF REQUESTED CHANGE
Delete use of word Frame in stream types.
RID RESPONSE:
In the context of Streams 'Frame' does have a real meaning and we do need to name Streams that are 
marked on fixed or variable boundaries with some type of 'Frame Sync Marker'
It could be argued that frame should have been called 'Container'.  Recommend new names instead of 
simply dropping 'Frame'.
RID STATE:	CLOSE

Resolution:
In the context of Streams 'Frame' does have a real meaning and we do need to name Streams that are marked on fixed or variable boundaries with some type of 'Frame Sync Marker' It could be argued that frame should have been called'Container'.  
Close

DESCRIPTION OF REQUESTED CHANGE
Remove PCM from name PCMStreamType.
RID RESPONSE:
XTCE does not include analog modulation schemes, but clearly does begin with PCM streams (nrzl, nrzm, nrzs, …).  This is important to do because it's possible for a container etc. to include segments of streams encoded with varying PCM types.
RID STATE:	CLOSE

Resolution:
XTCE does not include analog modulation schemes, but clearly does begin with PCM streams (nrzl, nrzm, nrzs, ...).  This is important to do because it's possible for a container etc. to include segments of streams encoded with varying PCM types.
Close

DESCRIPTION OF REQUESTED CHANGE
Modify text to specify that parameter can be member of multiple ParameterSets.
RID RESPONSE:
Ref'ing in XTCE is liberal.  That is MetaCommand in another MetaCommandSet can be Ref'd into 
another.  If not this needs to be explicitly captured in terms of "Ref Scoping". The Description does 
not match the supporting analysis.  There already is a MetaCommandRef in MetaCommand in MetaCommandSet.
RID STATE:	CLOSE

Resolution:
Ref'ing in XTCE is liberal.  That is MetaCommand in another MetaCommandSet can be Ref'd into another.  Closed

DESCRIPTION OF REQUESTED CHANGE
Modify Figure 9 to depict relationship between interlocks and constraints.
RID RESPONSE:
Even though an Interlock is a type of contraint, we were unable to use this relationship in the realization of Interlock in the W3C schema and since the UML was generated automatically from the schema, this relationship does not appear in the UML.  As we'd prefer to keep the UML generation completely autogenerated.
RID STATE:	CLOSE

Resolution:
Even though an Interlock is a type of contraint, we were unable to use this relationship in the realization of Interlock in the W3C schema and since the UML was generated automatically from the schema, this relationship does not appear in the UML.  As we'd prefer to keep the UML generation completely autogenerated, close.

DESCRIPTION OF REQUESTED CHANGE
Delete ", but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. " Modify "An Interlock will block successive commands until this command has reached a certain stage (through verifications)." to "An Interlock will block the command until a previous command has reached a certain stage (through verifications)."
RID RESPONSE:
The proposed wording change would change the meaning of Intelock in XTCE.  The proposed changes are not what was intended to be the definition of an Interlock.  The proposed definition of Interlock would be a type of TransmissionConstraint.
RID STATE:	CLOSE

Resolution:
The proposed wording change would change the meaning of Interlock in XTCE.  The proposed changes are not what was intended to be the definition of anInterlock
Close

Interlock Scope
DESCRIPTION OF REQUESTED CHANGE
Modify "Interlocks are scoped to a SpaceSystem basis" to "Multiple types of interlocks can be specified, each specific to a distinct SpaceSystem state".
RID RESPONSE:
Related to RID-068.  Proposed wording would change the meaning of interlock scope.  Currently, 
XTCE Interlocks, (or Constraints, or Verifiers) do not have Context (state) differentiation.
RID STATE:	CLOSE

Resolution:
The proposed wording change would change the meaning of Intelock in XTCE.  The proposed changes are not what was intended to be the definition of anInterlock
Close

DESCRIPTION OF REQUESTED CHANGE
Explain exact meaning of verifier stages.
RID RESPONSE:
Related to RID-70.  XTCE does not currently have any mechanism to specifiy expection reaction to a 
command that is 'interuppted'.  Each verifier type is associated with a command processing 'state' and 
is explained (though with brevity) in the document.
RID STATE:	CLOSE

Resolution:
The verifier changes were addressed in issue 10264  XTCE does not currently have any mechanism to specifiy expected reaction to a command that is 'interrupted'.
Close

Allow variable number of significance levels each with variable value (name).
RID RESPONSE:
As the goal is a standard exchange, the six level of significance can be exchanged and should be sufficient This conversation has become muddled, each command can have six significance level (none, watch, distress, warning, critical, severe).  Are more than six levels required?  The current six map directly to 
the six levels of alarm severity.
RID STATE:	CLOSE

Resolution:
As the goal is a standard exchange which variable numbers would increase complexity of exchange, six levels of significance can be exchanged and should be sufficient . Closed.

DESCRIPTION OF REQUESTED CHANGE
Include statement of precedence between schema defined in Annex A and specification document body.
RID RESPONSE:
The introduction in overview states "normative portion of this specification is presented as a single 
XML schema .." 6.3 states the schema is the normative specitication.  The UML is automatically generated from the schema.
RID STATE:	CLOSE

Resolution:
The introduction in overview states "normative portion of this specification is presented as a single XML schema .." 6.3 states the schema is the normative specitication.  The UML is automatically generated from the schema. Closed

DESCRIPTION OF REQUESTED CHANGE
To be used within ESA projects, any data exchange mechanism shall ensure the integrity of the data that is exchanged. The proposed XTCE standard does not comply with this basic requirement and as 
such cannot be used to safely transfer data.
RID RESPONSE:
·	XML schema provides type checking thru schema validation, may be somewhat helpful here
·	any translation should document what "falls out" if anything to another user, that seems unavoidable
	
	
With appropriate guidelines, magenta book, and maybe one for PUS or E70-31, XTCE can be used 
without any ambiguity in the data contained.
We don't agree with the basic assertion : "The proposed XTCE standard does not comply with this 
basic requirement (ensure the integrity of the data that is exchanged) and as such cannot be used to 
safely transfer data".  We don't understand the supporting analysis "does not guarantee unicity of their
content interpretation".  If all the world used SCOS, then XTCE does not have value - all the world 
does not use SCOS.  If a new schema is created for every supplier/customer contract, then we don't 
have a standard exchange format.
RID STATE:	CLOSE

Resolution:
XML schema provides type checking thru schema validation, may be somewhat helpful here - any translation should document what "falls out" if anything to another user, that seems unavoidable

With appropriate guidelines, magenta book, and maybe one for PUS or E70-31, XTCE can be used without any ambiguity in the data contained.

We don't agree with the basic assertion : "The proposed XTCE standard does not comply with this basic requirement (ensure the integrity of the data that is exchanged) and as such cannot be used to safely transfer data".  If a new schema is created for every supplier/customer contract, then we don't have a standard exchange format. Closed

DESCRIPTION OF REQUESTED CHANGE
Please remove default values. When values are not set (when it is not desirable to set them, or not useful), then they are set to default after the validation of the XTCE file. This is clearly not wanted, as it adds info that is not wanted.  Please, do not put defaults everywhere, only when necessary.
For instance, that case happens for boolean parameters, when suddenly a True/False association appears and lead to a new calibration generation because the attributes are not nul. Although in principle there is no calibration.
RID RESPONSE:
Closed - I withdraw this rid, this is a problem relevant to specific implentation of XML parses, schema is ok.
RID STATE:	CLOSE

Resolution:
Closed - Issue withdrawn after discussion this is a problem relevant to specific implementation of XML parses, schema is ok.

DESCRIPTION OF REQUESTED CHANGE
From "… be able to transition a spacecraft mission …" to "… be able to move a spacecraft mission 
	…"
	
RID RESPONSE:
We believe transition a mission by moving a database reads better
RID STATE:	CLOSE

Resolution:
We believe transition a mission by moving a database reads better
Close

DESCRIPTION OF REQUESTED CHANGE
From "… very powerful means define TDM telemetry streams…" to "… very powerful means to define TDM telemetry streams…"
RID RESPONSE:
This entire sentence was modified as a result from a previous RID
RID STATE:	CLOSE

Resolution:
This entire sentence was modified as a result from a previous RID
Close

DESCRIPTION OF REQUESTED CHANGE
Delete the satellite picture inset in Figure 1, considering that the specification may be also equally applied to a Ground Equipment which, in turn, is not represented by a picture, in the same figure.
RID RESPONSE:
Yes, but the figure does say spacecraft or ground equipment.
RID STATE:	CLOSE

Resolution:
The figure does say spacecraft or ground equipment. Closed

DESCRIPTION OF REQUESTED CHANGE
Paragraph 2, item 4, says the specification supports: Data representation definition 
Paragraph 3, item 5, says the specification does NOT supports: Data representation (visualization properties)  The text does not clarify the precise meaning of data representation, in both cases. These two items, in separate, should precisely describe the difference in data representation, each of them actually are intended to support.
RID RESPONSE:
As a result of an earlier RID this section has already be extensively re-written.
RID STATE:	CLOSE

Resolution:
As a result of an earlier RID this section has already be extensively re-written.
Close

DESCRIPTION OF REQUESTED CHANGE
Considering the difficulty of checking the schema, it is recommended the inclusion of an additional annex for serving as a guide for its use. It is advised that such an annex could consider how the XCTE schema could, for instance, instanciate a CCSDS TM source packet file. And or, consider including some of the examples that can be drawn from the contents of the files which were pointed by the editor in his request for this review.
RID RESPONSE:
If an end-user decides to extend or use XTCE in a unique manner, that information will need to be 
documented for another party. Please read the support documentation of XTCE (Magenta Book and 
Green Book)
A growing body of examples is becoming available.
RID STATE:	CLOSE

Resolution:
Please read the support documentation of XTCE (Magenta Book and Green Book).  A growing body of examples is becoming available.  Specification is sufficient, it is expected that more documentation on appropriate use will be developed.
Close.

DESCRIPTION OF REQUESTED CHANGE
The summary does not contain the list of all the figures of the document.
RID RESPONSE:
The Table of contents was generated from the OMG template format which was in turn generated from the ISO PAS format; neither include a list of figures or tables.
RID STATE:	CLOSE

Resolution:
The Table of contents was generated from the OMG template format which was in turn generated from the ISO PAS format; neither include a list of figures or tables.
Close

DESCRIPTION OF REQUESTED CHANGE
6.	Change history
RID RESPONSE:
SpaceSystem/Header/HistorySet provides a simple mechanism for capturing history change.
RID STATE:	CLOSE

Resolution:
SpaceSystem/Header/HistorySet provides a simple mechanism for capturing history change.
Close

DESCRIPTION OF REQUESTED CHANGE
2.	Definition of all the legal Spacecraft IDs
	
The spacecraft id or SCID is an integral part of most space databases. Is there an element for this in XTCE? I can't seem to find it. Also what if someone wants to use a SCID that is already taken? XTCEcould have a documentation note for users to check a list hosted by CCSDS???
RID RESPONSE:
Spacecraft IDs are perfectly accomodated in the SpaceSystem's AliasSet. Even more than one spacecraft id can be accomodated in the AliasSet. The correct namespace has to be used and can SpacecraftID1, SpacecraftID2 and so o
it reflects current information etc. The current tag author, name, date, comments etc. I think FSW also 
.
RID STATE:	CLOSE

Resolution:
Spacecraft IDs are perfectly accomodated in the SpaceSystem's AliasSet .
Close

DESCRIPTION OF REQUESTED CHANGE
7.	Repeated arguments
RID RESPONSE:
This needs to be combined with another RID of similar issue.  In XTCE, arguments are deemed as input from the user.  The command parameter is machine set.  Command parameters are repeatable, but arguments are not.   If you need to repeat something on the command-size, use the parameters in that section to defined them and then use the RepeatEntry element in EntryList/ParameterRef/RepeatEntry to specify repeats.
Closed by AO
RID STATE:	CLOSE

Resolution:
In XTCE, arguments are deemed as input from the user.  The command parameter is machine set.  Command parameters are repeatable, but arguments are not.   If you need to repeat something on the command-size, use the parameters in that section to defined them and then use the RepeatEntry element in EntryList/ParameterRef/RepeatEntry to specify repeats. Closed

DESCRIPTION OF REQUESTED CHANGE
8.	Fill arguments
RID RESPONSE:
Fill can be specified by using the BinaryParameterType or BinaryArgumentType to specify a fixed size block of bits, and that block can be referenced in the container (thru parameter/argument) as is necessary to specify a fill area.
Closed by AO
RID STATE:	CLOSE

Resolution:
Fill can be specified by using the BinaryParameterType or BinaryArgumentType to specify a fixed size block of bits, and that block can be referenced in the container (thru parameter/argument) as is necessary to specify a fill area.
Close

DESCRIPTION OF REQUESTED CHANGE
9.	Documentation entities
RID RESPONSE:
There are several documenation entities in XTCE,  LongDescription, shortDescription, AncillaryDataSet, and Header all provide opportunties to document items.
RID STATE:	CLOSE

Resolution:
There are several documenation entities in XTCE,  LongDescription, shortDescription, AncillaryDataSet, and Header all provide opportunties to document items.
Close

DESCRIPTION OF REQUESTED CHANGE
10.	Would need to kludge for "fixed" area's in commands (aka not set by parameter)

RID RESPONSE:
This is the same RID JPL-006
RID STATE:	CLOSE

Resolution:
This is the same RID SOURCE:JPL-006, Issue 10213
Close

DESCRIPTION OF REQUESTED CHANGE
11.	Alarm on change, or on delta change (ESA-0016)
RID RESPONSE:
XTCE telecon: new proposal. To be accepted by KR, GS, JM
The alarm on change is a bit general, and is then generally covered  by XTCE already.
Refer to ESA016, this one is considered duplicate of ESA016
RID STATE:	CLOSE

Resolution:
Duplicate of issue 10158, ESA-016
Close

DESCRIPTION OF REQUESTED CHANGE
12.	Table lookup algorithm
	
There should be more information on how to use these algorithms, what they look like (type syntax 
etc). <complexType name="AlgorithmSetType" mixed="false">
<annotation>
<documentation>An unordered collection of algorithms</documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="CustomAlgorithm" type="xtce:InputOutputTriggerAlgorithmType"/>
<element name="MathAlgorithm" type="xtce:MathAlgorithmType"/>
</choice>
</complexType>
CATEGORY OF REQUESTED CHANGE SUPPORTING ANALYSIS RID RESPONSE:
Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID 
does not apply to XTCE schema.
RID STATE:	CLOSE

Resolution:
Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID does not apply to XTCE schema.
Close

DESCRIPTION OF REQUESTED CHANGE
13.	Not specified how to plug in external algorithms/code
	
The element is <element name="CustomAlgorithm"type="xtce:InputOutputTriggerAlgorithmType"/>. The question is HOW do you plug in these external algorithms? It should be included in the tutorial.
RID RESPONSE:
Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID 
does not apply to XTCE schema.
RID STATE:	CLOSE

Resolution:
Algorithms are explained in the Magenta Book. The explanations there will be reviewed, but the RID does not apply to XTCE schema.
Close

DESCRIPTION OF REQUESTED CHANGE
14.	Need repeats blocks in commands, with a length
RID RESPONSE:
This is the same JPL-005
XTCE commands have the following underlying Model.  Arguments are something set by a human at an "ops console".   Command-parameters are set by machine.   In XTCE, the repeat of Argument type isn't currently supported because of this division.  If the repeat is needed, a command parameter should be defined and used for this purpose.If repeat of human-settable arguments is needed, this would be a schema change.
RID STATE:	CLOSE

Resolution:
Duplicate of issue 10212 (JPL-005).
Close.

DESCRIPTION OF REQUESTED CHANGE
15.	A way to specify "meta" framing in commands
	
I believe the general idea is that the metadata segment provided with the command container type could also be framed in various ways. Metadata could also contain custom information such as the command name, command priority, size of packet or any housekeeping information such as transaction IDs. My guess is that this metadata could used for command filtering, accountability and traceability and there could be layers of metadata. My reading of this is that user may want some flexibility on how to use and where to place metadata …
RID RESPONSE:
It will be checked again with the author. But all what has been described is covered by XTCE. How 
this is covered is in the Magenta Book, and also will be explained and followed up by Kevin.
RID STATE:	CLOSE

Resolution:
All that has been described is covered by XTCE. Recommended practices are covered in the CCSDS Magenta Book.
Close

DESCRIPTION OF REQUESTED CHANGE
the namespace of all space domain entities belongs to the CCSDS.
RID RESPONSE:
I'm not sure namespace really matters other than ensuring that it's unique Your comment about CCSDS owning all space domain entities is - to say the least -  adversarial.
The namespace was set at the OMG over five years ago.
RID STATE:	CLOSE

Resolution:
The namespace was set at the OMG over five years ago.
Close

DESCRIPTION OF REQUESTED CHANGE
It ignores the flight software developer as a principle user of a command and telemetry database.
RID RESPONSE:
"Ignores the flight software developer" is a non specific, non-constructive comment.  Please recommend specific changes or enhancements.
This is only true for certain types of missions.  The scope of XTCE is clear: telemetry and 
commanding, alarms and calibrator for them, services, some (minimal) stream info and alrgorthm with a 
heavy bent towards mission ops.  Flight software needs were not really formally discussed and viewed
pretty much as out of scope.
Future work in this area would be welcome.
RID STATE:	CLOSE

Resolution:
Future work in this area would be welcome, but is not within the scope of the current XTCE specification.
Close

DESCRIPTION OF REQUESTED CHANGE
Also, the Schema need arrays in telemetry, one option is "repeat array until end of packet". It also needs to define a type/length/value structure definition in telemetry.
RID RESPONSE:
This is related to JPL-005 and at least on other.XTCE has an array-type.  XTCE also allows one to specify that a container parameter repeats some number of times.   That number of time can be looked up in other location.However, it does not allow "Repeat until 'end of container'"-that's an interesting idea and seem like it could be easily added if there's broad consensus for its usefullness.A representive specific Schema Change would have to be developed and submitted.
RID STATE:	CLOSE

Resolution:
XTCE has an array-type.  XTCE also allows one to specify that a container parameter repeats some number of times.   That number of times can be looked up in other location. However, it does not allow "Repeat until 'end of container'" -- that's an interesting idea and seem like it could be easily added if there's broad consensus for its usefulnes

DESCRIPTION OF REQUESTED CHANGE
Monolithic Schema results in - Huge, unmanageable XML files
RID RESPONSE:
BUT it should be noted.  XTCE doesn't require that document be MONOLITHIC.  It is true that the Schema is in one document.  But one can save each indiviual parameterType in your document to a separate file if that's what you wish to do.  Each of those would be a valid XTCE document because much of the top-levels of the schema are optional.So, it possible split up any XTCE document into several "parts" if that's needed.It should be noted that XML does tend greatly increase the size of documents but that at the moment the large size of desktop memory for cost, seems to put this issue into something that is easily managed.
RID STATE:	CLOSE

Resolution:
Duplicate of issue 10172 which was deferred. Close.

DESCRIPTION OF REQUESTED CHANGE
4.	FSW information such as:
(a)	FSW command-message method name
(b)	FSW data structure mapping information
(c)	FSW enumerated data mapping information
(d)	FSW data type information
(e)	FSW argument name
(f)	FSW include file names
RID RESPONSE:
This is related to several other RIDs.  At the moment there is nothing specific about FSW in XTCE, however AncillaryData may be useful for capturing this information.
RID STATE:	CLOSE

Resolution:
This is related to several other RIDs.  At the moment there is nothing specific about Flight Software in XTCE, however AncillaryData may be useful for capturing this information.
Close

DESCRIPTION OF REQUESTED CHANGE
The common data definitions should be refactored to extract common metadata items that can be reused
in other CCSDS schemas. These common metadata items are:
A.	Time formats
a.	UTC Time format
b.	Spacecraft clock (SCLK) time format
c.	Earth receive time (ERT) format
d.	GMT time format
e.	Time Period format
B.	Basic types
C.	Algorithms
D.	Units types
E.	Coordinate formats
a.	Cartesian formats for reference frame formats
b.	J2000 + other celestial body formats
RID RESPONSE:
None of these specific time formats are part of XTCE now, but should be definable in an valid XTCE XML document.XTCE doesn't know anything about specific formats in CCSDS and was designed to be general enough to describe them (should it fail then that's a valid criticism for schema change).  If it would be helpful, CCSDS could supply base XTCE documents for those specific format for missions that could be downloaded from the CCSDS web site.
RID STATE:	CLOSE

Resolution:
XTCE does not pre-define specific formats, such as CCSDS.  It was designed to be general enough to describe CCSDS formats as well as time-division-multiplexed formats.  Reuse can be guided by the related CCSDS Magenta Book
Close

DESCRIPTION OF REQUESTED CHANGE
9.	Ensure that all the sub-schemas have the same namespace.
RID RESPONSE:
Merge this with other RIDs (JPL-016, etc…) on seperating out the schema
RID STATE:	CLOSE

Resolution:
Duplicate of issue 10172. Close

DESCRIPTION OF REQUESTED CHANGE
6.	Elaborate on the "fixed" uplink bit-stream format … information from constant updates, as telemetry channel/evr/product information is changed, and unmanageably large file sizes.I think this has to do with Custom Stream sets. The concern is how does XTCE affect the file sizes of elemetry streams. Does XTCE impose an overhead on this? Using XTCE to generate telemetry stream would be interesting … is it efficient?
RID RESPONSE:
It would only DESCRIBE a telemetry stream and what it can describe about streams themselves is pretty minimal.  Unless I misunderstand things I don't think there should be any problems here.There is no overhead imposed by XTCE, it is just the description of data..
RID STATE:	CLOSE

Resolution:
XTCE onlys describes the command and telemetry streams, it not used for sending telemetry or commanding.  While the size and overhead of an exchange format is a consideration, it is not critical to the functionality, and the widespread availability of XML based tools to manipulate the data is a more important consideration.
Close

DESCRIPTION OF REQUESTED CHANGE
8.	Include (using XML include command) all these schemas in a one container schema such as SpaceSystem.xsd
RID RESPONSE:
Merge this with the other RIDs (JPL-016, JPL-22) on seperating the schema
RID STATE:	CLOSE

Resolution:
Duplicate of issue 10172. Close

DESCRIPTION OF REQUESTED CHANGE
4.	Ensure the command schema is useful for mission operations (ingest by command sequencing engine, command scripting).
RID RESPONSE:
The OMG sees this addition as a separate standard
Similar to previous RIDS.  Please follow (and contribute!) to the OMG SOLM specificaton.
RID STATE:	CLOSE

Resolution:
Future work in this area would be welcome, but is not within the scope of the current XTCE specification.
Close

DESCRIPTION OF REQUESTED CHANGE
3.	Add provisions to the command schema to accommodate flight software developers (see Section A.above) and system integrators (automatic code generation, command and code documentation).
RID RESPONSE:
AncillaryDataSet has been added that may help in this area-it allows for "tag/text" type descriptions to be created.  However, nothing specific to flight software has been added, work in this area could be attmpted in the future however. This is also similar to JPL-019, suggest merging.
RID STATE:	CLOSE

Resolution:
AncillaryDataSet has been added that may help in this area-it allows for "tag/text" type descriptions to be created.  Nothing specific to flight software has been added. Close

DESCRIPTION OF REQUESTED CHANGE
1.	Extract common metadata and other generic items that can be reused in other CCSDS schemas, and add provisions for those that are missing (time and location representation).
RID RESPONSE:
The time and location issue has been discussed in RID JPL-020.
RID STATE:	CLOSE

Resolution:
Duplicate of 10226. XTCE does not pre-define specific formats, such as CCSDS.  It was designed to be general enough to describe CCSDS formats as well as time-division-multiplexed formats.  Reuse can be guided by the related CCSDS Magenta Book.  The time and location issue is a duplicate of issue 10173.
Close

DESCRIPTION OF REQUESTED CHANGE
 Future examples should demonstrate onboard EH&A and Event Reporting (EVR) translation to an XTCE compliant XML document. Telemetry contains EH&A and EVR information. This information can be translated into an XTCE compliant document when downlink is complete.EH&A is Engineering, Housekeeping and Accountability data. It is usually data from sensor XYZ (thermocouples, currents, voltages). EVR are basically ERROR/EVENT log messages. Usually these are captured in an XML file that is leveraged by ground or flight software in some way. For instance the types of events or types of EH&A data are captured in an xml file that sits on the ground and is used to parse telemetry OR this XML file is translated to C code modules that are embedded in the flight code.
RID RESPONSE:
This is already covered in XTCE telemetry. Please review if this is not the case. Although SOLM is on progress, and as a metamodel may accommodate further needs.
RID STATE:	CLOSE

Resolution:
Events can be described in XTCE.  An event report from the spacecraft must be in a defined format, identifiable by the ground software, which should be describable as a Container in the same way as other telemetry.
Close

DESCRIPTION OF REQUESTED CHANGE
1.	System Engineering items, such as spacecraft mode phases, command classes/categories/themes & descriptions (i.e. this is a motor command, camera command etc)
RID RESPONSE:
Please revew the  XTCE 'Contexts' alarms, calibrators and command area-in addition TCE Commands may be grouped by sub-system (e.g., motor, camera, etc.)
RID STATE:	CLOSE

Resolution:
Please revew the  XTCE 'Contexts' alarms, calibrators and command area.  In addition, XTCE Commands may be grouped by sub-system (e.g., motor, camera, etc.)
Close

	Remove paragraph as defaults have been removed from the Schema
	RID STATE:	FIXED

Revised Text:
6.1.6	Defaults
Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem.  These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves.  Defaults simply provides a means to avoid repeating attributes such as 'bit order' for every Type definition.
----
Removed

"Very robust" should be deleted.
	RID STATE:	FIXED

Resolution:
Fixed

Label all arrows in figure.figure 1 are not labeled.
	RID STATE:	FIXED

Resolution:
Fixed

	"and operation" should be appended to "The scope of this specification is limited to satellite telemetry and commanding data constructs necessary to support satellite and payload data design:"
	RID STATE:	FIXED

Resolution:
Fixed

	Change "This specification addresses only the definition of TM/TC data, and not the transfer of live or historical TM/TC data." to "This specification addresses only the definition of TM/TC data in the ground segment, and not the transfer of live or historical TM/TC data."

	RID STATE:	FIXED

Resolution:
Fixed

"All measurements on board the spacecraft are transmitted to the ground system in a telemetry stream" should be modified to "Measurements collected on board the spacecraft may  be transmitted to the ground system in a telemetry stream". "Telemetry as used here refers to these measurements whether on-board the spacecraft or transmitted to the ground system." should be modified to "Telemetry as used here refers to those measurements that are transmitted from the spacecraft directly or through ground equipment".
	RID STATE:	FIXED

fixed

	"Satellite commands are transmitted from the ground system directly to the spacecraft or through ground equipment." should be added
	RID STATE:	FIXED

fixed

	Add quotes and reference to source of command definition (similar to telemetering definition above). Add reference to "CCSDS Telemetry and Commanding Packaging format".
	RID STATE:	FIXED

fixed

"IEEE Std 1000" should be corrected to "IEEE Std 100-1996". Also [1972] should be updated to 
	[1996] : definition has not been modified.	Fixed in the new document
	RID STATE:	FIXED

fixed

	Change "provides dereference to the fact that" to "refers to the fact that"
	RID STATE:	FIXED

fixed

The symbols and concepts used in the class diagrams to present the XTCE specification need to be referenced. The symbols and concepts also need to be explained (e.g. classes/objects, associations, multiplicity, aggregation, inheritance, attributes, operations).
	RID STATE:	FIXED

	Define term "anonymous type"
RID STATE:	FIXED

Modify text to specify that parameter can be member of multiple ParameterSets.
	RID STATE:	FIXED

Clarify "string conversion specifications and calibrations."
	RID STATE:	FIXED

Precisely define each encoding type.
	RID STATE:	FIXED

Clarify types in Figure 4.
		RID STATE:	FIXED

fixed

Replace sentence "Sequence Containers are a simple yet very powerful means define [sic] TDM 
	telemetry streams (to any commutation level), packetized streams or many other package formats." with sentences moved from  paragraph 2 "A SequenceContainer may represent a packet, frame, a subframe, or any other grouping/structure of data items. The simple form of a Sequence element is an ordered set of Parameter References or other Container References." Change "Sequence element" to "Sequence Container"
	RID STATE:	FIXED

fixed

	Describe all the elements shown in Figure 5.
	RID STATE:	FIXED

	Define the relationship between messages, containers and services.
	RID STATE:	FIXED

Issue resolved at the same time as issue 10254, changed text is shown there

Describe MatchCriteria class and how criteria are to be explicitly specified.
	RID STATE:	FIXED

	Describe all elements of Figure 6 in text.
	Fixed in the new document.
	RID STATE:	FIXED

Fixed - updated text and associated diagram

	Describe in text all classes, associations and attributes in Figure 7.
	Fixed in the new document.
	RID STATE:	FIXED

6.1.3.6	AlgorithmSet
An AlgorithmSet is an unordered collection of Algorithms.  In spacecraft ground systems, it is necessary to perform some specialized processing to process the telemetry, and preprocess commands.  There are a number of predefined algorithms and the algorithm section makes it possible to reference externally defined algorithms for arbitrarily sophisticated data processing.
6.1.3.6.1	MathAlgorithm
A Math Algorithm is a simple mathematical operation with two operands (each of which may be a fixed or a parameter instance value) and an operand. 
6.1.3.6.2	SimpleAlgorithm
A simple algorithm only has an optional Algorithm Text (for pseudo code) and Set of names to external algorithms (which be really be Java class files, DLLs, scripts, etc.).  There is a set of external algorithms so one XTCE file can be used across multiple platforms.  
6.1.3.6.3	InputAlgorithm
An InputAlgorithm is a type of SimpleAlgorithm that also has a set of inputs.  These inputs may be named Parameter Instances or constants.
6.1.3.6.4	InputOutputAlgorithm
An InputOutputAlgorighm is a type of InputAlgorithm that also has a set of outputs.  These outputs are named ParameterRefs.  
6.1.3.6.5	InputOutputTriggerAlgorithm
An InputOutputTriggerAlgorithm is a type of InputOutputAlgorithm that also has a set of Triggers. Triggers are used to 'fire' the algorithm and may be either periodic, or event based (new parameter or container instance).

Add definitions of parameter segment, stream segment and container segment to text.
	RID STATE:	FIXED

fixed

Discuss and depict relationships between Parameter used for telemetry and Parameter used for 
	command, command interlock, verifier, or parameter to set.
	
	RID STATE:	FIXED

Issue is a duplicate of 10154 and is resolved.

Clarify "data type" and "data encoding type" in Figure 8.
		RID STATE:	FIXED

Issue is a duplicate of 10260 and is resolved.

	Describe all elements shown in Figure 8 in text.
	RID STATE:	FIXED

Figure 8 replaced and revised descriptions as a result of 10154.

	Precisely define each encoding type.
	RID STATE:	FIXED

Disposition:  Duplicate 10161,10249

Describe all elements shown in Figure 9 in text.
	RID STATE:	FIXED

fixed

	Include description of ParametersToSuspendAlarmsOnList and capabilities to initiate alarm based on command parameters.
	RID STATE:	FIXED

Resolution:
Fixed
Revised Text:
Included in text revisions for 10262.

	Modify "that provides positive indication on the successful execution of a command" to "that provides positive indication on the processing stage of a command." Modify "command completion" to "command processing". Modify "Execution" to "Executed" and "Complete" to"Succeeded". Modify "multiple completion verifiers" to "multiple command verifiers", and "completed verifiers are added" to "command verifiers are added". Clarify "All others will replace a verifier defined in a Base MetaCommand" Ideally, allow variable number of verifiers each with variable value (name).
	
RID STATE:	FIXED

Resolution:
Fixed
Revised Text:
Included in text revisions for issue 10262.

	Add description of difference between a Parameter (page 17) and a ParameterToSet
		RID STATE:	FIXED

Resolution:
Fixed
Revised Text:
Included in text revisions for issue 10262.
Disposition: Resolved

	Describe how transmission constraints are to be explicitly specified.
	RID STATE:	FIXED

Resolution:
Fixed
Revised Text:
Included in text revisions for issue 10262.
Disposition: Resolved

Describe all elements shown in Figure 10 in text
	RID STATE:	FIXED

Resolution:
Fixed

From "Parameters may be or variable length." to "Parameters may be of variable length."

Resolution:
Fixed

	Paragraph 1From: " This XML Telemetric and Command Exchange (XTCE) data specification answers the need for an information model and data exchange format for telemetry and commanding in all phases of the spacecraft, payload, and ground segment lifecycle: system design, development, test, validation, and mission operations." To: "This XML Telemetric and Command Exchange (XTCE) data specification presents a robust information model and data exchange format for telemetry and commanding in all phases of the spacecraft, payload, and ground segment lifecycle: system design, development, test, validation, and mission operations."
	 	RID STATE:	FIXED

fixed

	Paragraph 1
	 
	From: "Purpose: This specification is an information model and data for spacecraft telemetry and 	commanding data. For a given mission … at each step in the lifecycle." 	 
	To: 
	"Purpose: This recommendation is aimed to the specification of an information model for spacecraft 	telemetry and commanding data. This model will allow a spacecraft operator to transition a spacecraft 	mission from one ground system to another by simply moving a compliant, already existing command 	and telemetry database to another ground system, which equally supports this same model."	Dismembering the rest of the 1st. paragraph to become the second, additional paragraph, with the same original content, as:"For a given mission … at each step in the lifecycle."  Original paragraph 3 :"Ideally, a spacecraft operator … telemetry database specification."is proposed to be completely deleted.
	RID STATE:	FIXED

	Exchange the columns of the table referenced in section 3: the first column should come naturally first, 	containing the name of the recommendation, and the second column should come in second place, 	containing the corresponding URL e-address.
	RID STATE:	FIXED

fixed

	It is advised that the document should properly contain, possibly, in its Section 5, the definition of the 	following acronyms:
	 
	PCM  (referred in: page 8 - Section 1, second paragraph) 
	UTF  (referred in: page 21 - annex A - section A.2), 
	TDM  (referred in: page 6 - Introduction, page 14 - ContainerSet and page 21 - annex A),  
	SAX  (referred in: page  21 - annex A), 
	DOM  (referred in: page  21 - annex A)
		RID STATE:	FIXED

Fixed - Expanded acronym definitions

From: "… begin with a capitol letter. " 
	 
	To:      "… begin with a capital letter. "
	RID STATE:	FIXED

fixed

Phrase "containing the '/', '.', and ':' chararacters as these are reserved." is a	bit stilted.  Compare with phrase on Page 14 Line 1: "cannot contain spaces, '.', '/', '[' or ']' as these are 
reserved characters.".
	RID STATE:	FIXED

fixed

This diagram shows that NameDescriptionType is child of DescriptionType.
	This is true but no other class diagram shows this inheritance so Figure 4
	appears to be inconsistent.  It may be help to have a small paragraph
	discussing the relationship between DescriptionType, NameDescriptionType, and 
	OptionalNameDescriptionType near the beginning of the document.
	RID STATE:	FIXED

Fixed – Full Schema-Type inheritance chain no longer fully shown because it is not
relevant

	The <documentation> entries for parameterNameKey, parameterTypeNameKey, etc., are sentence fragments.  The <documentation> for all other elements are complete sentences (with capitalization 	and periods).
	RID STATE:	FIXED

fixed

	68 elements/attributes have <documentation xml:lang="en">...
	216 elements/attributes have <documentation>...
	Do you wish to specify a language or not?
	RID STATE:	FIXED

fixed

Typo in documentation for QueuedVerifier "<documentation>A verifyer ..."
	RID STATE:	FIXED

fixed

Typo in documentation for AutoInvert "for some number of bitss.  ..."
	RID STATE:	FIXED

fixed

	EnumerationAlarmType has <appinfo source="An additional check needs to be ..."
	The source attribute should point to URI not string.
	RID STATE:	FIXED

fixed

TYpo "... begin with a capitol letter."
	Text changes necessary.  Fixed
	RID STATE:	FIXED

fixed

The enumerated symbol used for division in the MathOperatorsType should match the "/" used conventionally in programming languages rather than the "\".

fixed

Some sections/pages refer to the old (1.0) xsd version: 1 - page v: Version 1.1: The source documents for this specification include: Formal version 1.0: formal/2005-08-01 Associated Schema files: formal/2005-08-02 (xsd) 2 - page 19: The XTCE normative specification is contained entirely as a W3C XML Schema. This schema is available as a standalone document at http://www.omg.org/space/xtce/SpaceSystem1.0.xsd [=> This link is incorrect ] 

Description Kevin Rice 2007-10-22 20:56:01 BST 
XTCE has several locations within it where values need to be supplied, in many
cases they may be calibrated or uncalibrated values and an associated attribute
is supplied which determines whether the value should be treated as such.  
However in some cases, no attribute is supplied and the default is to treat the
value as calibrated.   The problem is that this is inconsistent and may not
cover the common industry use cases, especially as related to alarms (limits).
This bug report lists all the areas that use such a value in XTCE where an
attribute is not supplied along with it to set whether the value should be
calibrated or not.  These areas need to be considered and an attribute supplied
if appropriate.  
The following list may not be exhaustive (although it needs to be) and some may
make more sense than others in terms of supplying calibrated or uncalibrated
values;  that needs to be determined (through use cases) and schema changes
applied consistently to all these areas in the next revision.
ParameterSet/parameter@initialValue
Verifiers/ParameterValueChange/Change@value
StringParameterType/SizeRangeInCharacters@min,max
StringParameterType/{Default|Context}Alarm/StringAlarmList/StringAlarm@patternMatch
EnumerationType/EnumerationList/Enumeration@value
EnumerationType/{Default|Context}Alarm/EnumerationAlarmList/EnumerationAlarm@enumerationValue
- (attributes is a string, is it the enum value, or is it label?)
IntegerParameterType/toString/RangeEnumeration
IntegerParameterType/StaticRangeAlarm
IntegerParameterType/ChangeAlarms
FloatParameterType/StaticRangeAlarm
FloatParameterType/ChangeAlarms 
RelativeTimeType/ChangePerSecondAlarms
ArgumentList/Argument@initialValue
ParameterToSetList/../NewValue

Description Kevin Rice 2007-10-22 20:58:07 BST 
XTCE does not support RangeEnumeration directly.  A RangeEnumeration maps a
label to a range of values.  Currently XTCE only has the simpler Enumeration
Type - one label, one value. The IntegerType/ToString/rangeEnumeration could be
used [note: label is missing].   But this is not strictly speaking a
"RangeEnumerationTypes".  (From Chris Simms/NASA-MSFC)

Description Kevin Rice 2007-10-22 21:00:29 BST 
IncludeCondition doesn't directly allow for certain types of comparisons except
through CustomAlgorithm - counter based sampling particular. This need is
related to supercomming or supersampling based on counts.
(NASA-MSFC, Chris Simms)
Comment 1 Kevin Rice 2008-05-21 21:40:25 BST 
Need to get more information -KR
Comment 2 Kevin Rice 2008-05-21 21:51:11 BST 
You could use MathOperator in AlgorithmSet to derive something from another
parameter and then use Condition (BooleanExpression) or Comparison in
IncludeCondition to compare to the final result, such as a mod of a counter

Description Kevin Rice 2007-10-22 21:02:49 BST 
Argument elements need to have their attributes or child elements set to
ARGUMENTxxx. Many of the major elements associated with ArgumentTypes seem to
have child or attributes that say "parameterXXX" instead of "argumentXXX". 
C-S/CNES
Ludovic Faure

Description Kevin Rice 2007-10-22 21:04:10 BST 
Move Alarms outside of Type area. Alarms may change a lot and it may be easier
to have them set in the Parameter area, further alarms and calibrators, as well
as the time types reference Parameters directly which seems inconsistent with
them being in types. 

C-S/CNES
Ludovic Faure

Description Kevin Rice 2007-10-22 21:05:42 BST 
Change where Array sizes are set from Container area to Parameter or Argument
area. It may make more sense to put the array sizing in the parameter or
argument area instead of in container where it is now.  Currently in XTCE their
size is set in the Container.  
C-S/CNES
Ludovic Faure

Description Kevin Rice 2007-10-22 21:06:59 BST 
Label missing in RangeEnumeration element in ToString in IntegerType

Description Kevin Rice 2007-10-22 21:08:06 BST 
Contextalarmlist/contextalarm in the enumarationType is not set to inf
elements; missing INF in schema element

Description Kevin Rice 2007-10-22 21:09:15 BST 
CheckWindow has no way to vary window size based on context

Description Kevin Rice 2007-10-22 21:10:29 BST 
ErrorDetectCorrect doesn't support Checksum, especially on command side

Description Kevin Rice 2007-10-22 21:11:43 BST 
Message, IncludeCondition and BaseContainer do similar things and should be
unified
Comment 1 Kevin Rice 2007-10-22 21:21:03 BST 
Message, IncludeCondition and BaseContainer do similar things and should be
unified

Description Kevin Rice 2007-10-22 21:17:55 BST 
Command Argument should have alarms; I have found one user that claims alarms
on USER INPUT arguments.  Therefore I believe we should generalize the schema
to having them both in parameters and arguments. In the end I believe we'll be
making arguments and parameters look exactly the same even if the nomenclature
stays separate.
Comment 1 Kevin Rice 2007-10-22 21:20:06 BST 
Command Argument should have alarms; I have found one user that claims alarms
on USER INPUT arguments.  Therefore I believe we should generalize the schema
to having them both in parameters and arguments. In the end I believe we'll be
making arguments and parameters look exactly the same even if the nomenclature
stays separate.

Description Kevin Rice 2007-10-22 21:31:25 BST 
It's a typo

Description Kevin Rice 2007-10-22 21:33:28 BST 
Parameter/TimeAssociation@offset -- current date type should be decimal for
holding offset.  Change the Date to offsetTimeInMillisec, and make it a decimal
type. It is possible to work around this by storing the milliseconds as a YEAR
date but its awkward:
0001-01-01+00:00
0002-01-01+00:00
9999-01-01+00:00, 10000-01-01+00:00

Description Kevin Rice 2007-10-22 21:36:19 BST 
AlarmType is abstract in the XTCE schema and this presents problems for some
code generators such as JAXB. AlarmType is set to abstract and the code
generated by JAXB means the class cannot be directly instantiated.  This would
present problems for some Alarms for certain parameter types that are of type
AlarmType directly. There may be several ways to fix this in the schema and
those should be analyzed.
CNES
Ludovic Faure

Description Kevin Rice 2007-10-22 21:37:38 BST 
AbsoluteTimeParameterType do not have alarm elements associated with it.  In
the current schema this may be by design -- an example of a usage for an
alarming absolute time could be helpful.  JWST claims to alarm on occurrences
of reverse time which in fact would probably be a packet ordering issue.

Description Kevin Rice 2007-10-22 21:38:51 BST 
MathOperators "^" should either be removed or expanded to include all bitwise
operators, add or remove operators in math operators.

Description Kevin Rice 2007-10-22 21:40:01 BST 
Clarification needed for ContainerRef check. Clean up the annotation -- it
says: "When verification is a new instance the referenced Container". This
doesn't make any sense.

It just means the verification is reached when you receive that container.  An
example might be sending a command to download memory then receiving a packet
with the memory download.

Description Kevin Rice 2007-10-22 21:41:16 BST 
Update annotation related to verifiers parameterValueChange. It's supposed to
mean the Delta change (you could just do a comparison check for a specific
value).  So if the current value is 10 and you're looking for a ValueChange of
2, then you'd need a new value that's greater than 12 for the Verifier to trip.
 The annotation should be clearer.

Description Kevin Rice 2007-10-22 21:42:34 BST 
Clarify the way percentComplete is specified.  Value should be constrained from
0 to 100.

Description Kevin Rice 2007-10-22 21:43:57 BST 
Making UnitSet required wastes instance file space, make UnitSet optional.

Description Kevin Rice 2007-10-22 21:46:32 BST 
UnitSet should just be a simple string, rename it to "Unit" and add the
attributes 'name' and 'description'.  However the element should have content
like:

<Unit name="metersPerSecond" description="meters per second">m/s</Unit>
Comment 1 Kevin Rice 2008-03-04 22:29:39 GMT 
Unit is actually a type "Any" which is clearly not what was intended either...
Comment 2 Kevin Rice 2008-04-18 14:54:47 BST 
Unit is not a Type ANY -- its set to MIXED but has not child elements.  In
XMLSpy '08 in grid mode it seems to initially accept mixed concept.  However
going to text will fail -- not validate.

The out of the box Java parser does not validate it either if there is mixed
content.

Suggest setting the mixed content attribute to FALSE to be -- well absolutely
correct.

Description Kevin Rice 2007-10-22 21:48:47 BST 
Some organizations wish to capture counts to units on the telemetry side & then
units to counts on command side (often called reverse or inverse calibrators). 
 In some cases they may wish to both for various reasons, often in testing
scenarios to validate their operation calibration. XTCE does not provide an
easy way to mark a calibrator as either 'reverse' or 'forward'.

Description Kevin Rice 2007-10-22 21:49:52 BST 
These are implemented slightly differently in the schema and this has
implications for the programmer & API.  It would be easier from the programmer
standpt if they were same underlying schema types.

Description Kevin Rice 2007-10-22 21:51:07 BST 
XMLSpy autogenerator issue, may be true for others. In some cases elements are
not themselves extensions creating a schema type but are complex types.  In
those cases the class name does not end up matching the element but the
included type. This is particularly noticeable in several parameterTypes --
array, aggregate and absoluteTime, and in ALL the argumentTypes.  It would be
better from a code mapping standpt to address this in the schema -- yes, just
so the autogenerator "looks right".

Description Kevin Rice 2007-10-22 21:52:34 BST 
In the schema, the parameter/arguments do not share a common root class until
NameDescriptionType.  All the types except for Time/Array & aggregate are
BaseDataTypes.  The Time types are BaseTimeDataTypes and array/aggregate just
have nameDescription as the root.  It would be better if they shared a common
"lower down" class/type that would be more indicative of what these really are
instead in nameDescription which is shared by many schema types in XTCE. It
effects the code -- instead having say List<CommonBaseDataType>  in Java.  One
gets List<NameDescriptionType> -- which works but isn't as type safe - it's too
generic.

Description Kevin Rice 2007-10-22 21:53:45 BST 
ValidRangeAppliesToCalibrated should be moved to ValidRange element. Right now
this attribute is in the main element for the datatype but should probably be
moved to a specific element to which it refers.

Description Kevin Rice 2007-10-22 21:56:02 BST 
UTF-8 and UTF-16 are actually multi-byte formats.  The character width field
just says "8" or "16" somewhat implying bit width per character which doesn't
really match UTF-8/16.  We should match them up.

Description Kevin Rice 2007-10-22 21:58:41 BST 
Keys for the ContainerSet check should read CommandContainerSet on the
commandMetaData portion and there is no key at all for ArgumentTypeSet. These
can be added with little effort although it seems many parsers ignore the keys.
Comment 1 Kevin Rice 2008-03-03 21:15:40 GMT 
Most of the keys in fact are incorrect in the Xpath designations.  For example
the parameterNameKey should read:

"xtce:TelemetryMetaData/xtce:ParameterSet/*|xtce:CommandMetaData/xtce:ParameterSet/*"

Most if not all the other keys have the same issue related to incorrectly
specifying the "xtce:" namespace and thus do nothing.

Further, they are all at the top of the schema and instead could be positioned
at each element of interest, this would help with the error message generated.

Finally, instead of using key, the "unique" tag could be used instead as this
is exactly what the keys are checking for, uniqueness.

Description Kevin Rice 2007-10-22 21:59:47 BST 
An optional name should be associated with context alarms and calibrators in
type.  This would particularly be useful to type inheritance, because same
'named' contexts could be overloaded.

Description Kevin Rice 2007-10-22 22:00:56 BST 
ROW major order seems to be the poorly described default in XTCE, COL major is
a less popular but unheard ordering of array cells in memory.  These are well
documented and understood constructs and conversion between them should be easy
for any implementer.  By providing an attribute to select the ordering we'll
support everything but custom orderings. Wikipedia has an excellent entry on
the topic.

Description Kevin Rice 2007-10-22 22:01:57 BST 
It's not really documented how a parameter whose size is determined dynamically
should react with segment entries which are fixed.  Should the user be warned
when they don't match?  In addition arrays can be split across its dimensions
by using the attribute lastEntryForThisArray, how does this interact with
segments or in combination with dynamic values in parameter lengths?  An array
in a container, referenced as a containerSegment should be considered as well.
This needs to documented.
Comment 1 Kevin Rice 2008-05-21 22:46:12 BST 
If you have a parameterRefEntry of dynamic length and parameterSegment next of
a fixed lenght -- BUT you really need to adjust the segment based on the
dynamic lenght.  This seems either impossible or difficult to do in XTCE at
this time.

Description Kevin Rice 2007-10-22 22:03:01 BST 
MetaCommand/CommandContainer should have the same semantics as Java private
Inner classes. Update annotation to reflect this.

Description Ludovic FAURE 2007-10-31 17:22:31 GMT 
The CNES recommendations suggest a way to define packets descriptions without
using inheritance. Actually, we define a unique generical packet (non-abstract
container) that contains the definition of all the packets for a given mission.
It is possible by using optional container and parameter entries, thanks to the
element IncludeCondition. 
This approach is equivalent to the inheritance approach (a XSLT translator has
been developped) and is simpliest to handle at the software level. What about
write this approach in the magenta book as OK approach?

This is a sample of the MB example, following our recommendations:

<xtce:ContainerSet>
        <xtce:SequenceContainer name="TMFrame" shortDescription="CCSDS TM
Frame" abstract="false">
          <xtce:EntryList>
            <xtce:ContainerRefEntry containerRef="AbstractTMFrameHeader"/>
            <xtce:ContainerRefEntry containerRef="AbstractTMPacket"/>
            <xtce:ContainerRefEntry containerRef="AbstractTMFrameTail"/>
          </xtce:EntryList>
        </xtce:SequenceContainer>
        <xtce:SequenceContainer name="AbstractTMFrameTail"
shortDescription="" abstract="true">
          <xtce:EntryList>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_OC"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_EC"/>
          </xtce:EntryList>
        </xtce:SequenceContainer>
        <xtce:SequenceContainer name="AbstractTMFrameHeader"
shortDescription="" abstract="true">
          <xtce:EntryList>
            <xtce:ParameterRefEntry parameterRef="CCSDS_FVERSION"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_SC_ID"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_VC"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_OP_CTRL"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_MS_CNT"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_VC_CNT"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_SECH"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_SYNC"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_ORDER"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_SEGM"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_FH"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_HV"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TF_HL"/>
          </xtce:EntryList>
        </xtce:SequenceContainer>
        <xtce:SequenceContainer name="AbstractTMPacket" shortDescription=""
abstract="true">
          <xtce:EntryList>
            <xtce:ParameterRefEntry parameterRef="CCSDS_VERSION"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_TYPE"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_SEC_HD"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_APID"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_GP_FLAGS"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_SSC"/>
            <xtce:ParameterRefEntry parameterRef="CCSDS_PLENGTH"/>
            <xtce:ContainerRefEntry containerRef="ComboPacket">
              <xtce:IncludeCondition>
                <xtce:BooleanExpression>
                  <xtce:ANDedConditions>
                    <xtce:Condition>
                      <xtce:ParameterInstanceRef
parameterRef="CCSDS_VERSION"/>
                      <xtce:ComparisonOperator>==</xtce:ComparisonOperator>
                      <xtce:Value>0</xtce:Value>
                    </xtce:Condition>
                    <xtce:Condition>
                      <xtce:ParameterInstanceRef parameterRef="CCSDS_TYPE"/>
                      <xtce:ComparisonOperator>==</xtce:ComparisonOperator>
                      <xtce:Value>0</xtce:Value>
                    </xtce:Condition>
                    <xtce:Condition>
                      <xtce:ParameterInstanceRef
parameterRef="CCSDS_SEC_HD"/>
                      <xtce:ComparisonOperator>==</xtce:ComparisonOperator>
                      <xtce:Value>0</xtce:Value>
                    </xtce:Condition>
                    <xtce:Condition>
                      <xtce:ParameterInstanceRef parameterRef="CCSDS_APID"/>
                      <xtce:ComparisonOperator>==</xtce:ComparisonOperator>
                      <xtce:Value>123</xtce:Value>
                    </xtce:Condition>
                  </xtce:ANDedConditions>
                </xtce:BooleanExpression>
              </xtce:IncludeCondition>
            </xtce:ContainerRefEntry>
          </xtce:EntryList>
        </xtce:SequenceContainer>
        <xtce:SequenceContainer name="ComboPacket" shortDescription=""
abstract="true">
          <xtce:EntryList>
            <xtce:ParameterRefEntry parameterRef="RST00006"/>
            <xtce:ParameterRefEntry parameterRef="RST01006"/>
            <xtce:ParameterRefEntry parameterRef="DHT10001"/>
            <xtce:ParameterRefEntry parameterRef="DHT10002"/>
            <xtce:ParameterRefEntry parameterRef="OST10040"/>
            <xtce:ParameterRefEntry parameterRef="AST10061"/>
            <xtce:ParameterRefEntry parameterRef="ASD00001"/>
            <xtce:ParameterRefEntry parameterRef="AST50225"/>
            <xtce:ParameterRefEntry parameterRef="MISC01"/>
            <xtce:ParameterRefEntry parameterRef="DST50556"/>
            <xtce:ParameterRefEntry parameterRef="DHT40000"/>
            <xtce:ParameterRefEntry parameterRef="DHT10005"/>
          </xtce:EntryList>
        </xtce:SequenceContainer>
      </xtce:ContainerSet>
Comment 1 Kevin Rice 2007-10-31 20:37:23 GMT 
Although using the "inline" includeCondition approach was never part of the
original ideas in XTCE, you are not the first person to use it in this manner. 
I think for me personally its purely a pragmatic issue.  I haven't look at in
detail to determine if there there is anything really horribly wrong with using
IncludeCondition in this way -- but let's assume there isn't, then should we
accept it and put in the Magenta Book?

I would favor it if it simplified early adoption by folks because the
inheritance mechanism is expensive to implement in a general manner, and the
message is going to be a little more expensive than this...

This is going to be true for folks that principally want to use XSLTs to
implement XTCE on the code side of things, although in the long run they may
find that they write code ... still if it allows for easier early adoption, to
me this isn't a bad thing.

I do know that some of the original early authors will likely be opposed... but
maybe not.

I think it deserves some study.
Comment 2 Johannes Stamminger 2007-11-12 09:38:49 GMT 
IMO both constructs are needed:

The inheritance by way of a BaseContainer is usefull for packet
identification/specialization. E.g. the datastream is known to provide only
CCSDS packets. Therefore in the XTCE instance the used generic CCSDS packet
layout is designed. Now imagine e.g. the secondary header containing an id of
the structure of the user data part of the packet (as used in COLUMBUS). Those
packets now get modelled by extending the generic CCSDS packet with the
RestrictionCriteria relaying on a specific id value in the secondary header
field.

The IncludeCondition is needed always e.g. when having a indication flag. E.g.
the secondary header flag in the CCSSD primary header, the packet may arrive
with or without the secondary header. Same for the checksum flag. There are
many different time formats. Which is actually delivered in the packet may be
indicated by use of one or more flags.
This cannot be solved by way of inheritance as then one would need to model any
combination of flag value.


So I agree on the recommendations to avoid use of IncludeCondition for packet
identification purposes - but IMHO there is need for this construct at least as
described above. This should be documented in the MB, too.
Comment 3 Ludovic FAURE 2007-11-13 16:03:03 GMT 
Johannes, do you think the inheritance used in your first example may be
replaced by includeCondition? 
I think we can have the structure of the user data part that exist, in a basic
packet, only if the secondary header id has a specific value. For me both
approach are equivalent.
Comment 4 Johannes Stamminger 2007-11-14 07:17:14 GMT 
Sorry Ludovic, but my answer is no. Technically it may be possible sometimes
but neither from semantics nor from readability/usability I feel this to be a
good idea. 
IMO it is the responsibility of the more concrete packet description to
identify itself, not the generic one.
Another point: the generic CCSDS packet description may be separated from the
concrete ones even in a different document and might get referenced from there
only. Then the generic description does not even know of all concrete packets
extending itself.
Comment 5 Ludovic FAURE 2007-11-14 08:48:17 GMT 
I think i understand your point of view. It is true that, in my TM description,
concrete packets are not explicitly identified. In fact in CNES tools, we dont
need  this identification (for the moment) that is why we dont use inheritance. 

Tools are working on a data flow model that is consistent with some CCSDS
format EAST, DEDSL, and soon XTCE. The model is made from paper description and
in a natural way by using existence conditions (discriminants). People that
make those description are not familiar with UML and OO, and because we dont
need packet identification, we suggest to not use XTCE inheritance. This is
only for TM part because for TC part we need this identification and we use
MetaCommand to make it possible.

I think our approach is not so incorrect, it is just a different vision that
matches our needs in a simple manner. Anyway, our tools may need in the future
to get informations about TM packet identification. For me the simplest way are
message instead of container because it permits to separate containers part
that is the data fields description and the semantic and identification of
packets part (that we dont need yet at cnes). For me those are different
description levels. Also, Messages are a solution to avoid inheritance for
people that are not familiar with. 

What do you think of it?

Description Ludovic FAURE 2007-10-31 17:31:13 GMT 
In the chapter 2.3.4.4, it is written that a packet is identified as a
non-abstract container that has a base container (or a message as well). I
think a packet can be a non-abstract container without base container. For
example, if the description contains only one container that defines a packet.
There is no base container whereas this is a packet.

Comment 1 Kevin Rice 2007-10-31 20:20:48 GMT 
XTCE assumes that you wish to supply identifying information with the container
definitions.  You don't have to do this if your system knows that certain
container names are certain packet definitions, but this is a little bit
outside of what XTCE supports in terms of what it considers is needed in for
common usage.

In XTCE the two ways you can supply this are through the inheritance mechanism,
and the message mechanism.  They are roughly equal at a simplistic level,
although the inheritance mechanism adds another "meta" layer to XTCE: an
inheritance model within the instance document.

Some have proposed using IncludeCondition to supply identifying infomation to
packets because this is easy to process using XSLTs, and avoids using either
message which requires looking up a Ref, or inheritance which either requires
at minimum a ref look up or some inheritance model implementation which is
harder...
Comment 2 Johannes Stamminger 2007-11-12 09:50:29 GMT 
I agree with the author, a packet does not need to have a BaseContainer.

E.g. the XTCE instance describes the general CCSDS packet layout. This includes
a secondary header with a project specific "packet id" parameter describing the
user data section structure of the packet.

For packets whose structure is not known at a receiver, the packet still needs
to be identified as a ccsds packet in basic. At least to read the packet length
field to determine the next packet's start. Here the matching packet
description is the generic CCSDS description in the XTCE instance *not* being
abstract and *not* having a BaseContainer defined.
Comment 3 Kevin Rice 2007-11-12 15:19:51 GMT 
Hmmm interesting use case.
Comment 4 Kevin Rice 2007-11-12 18:33:25 GMT 
I thought about this a bit more -- what has been described is really a case of
using RestrictionCriteria w/CustomAlg to supply the "identifying" info...

If you supply a container that is 'standalone' some other user will not know
what to do with it, unless you supply additional information. 

Therefore if that information can be supplied in the XTCE file itself, it would
be better ...

And still match the 'model' so far defined for supplying identifying
information in some form using the RestrictioCriteria (or Message)...
Comment 5 Johannes Stamminger 2007-11-13 07:13:54 GMT 
Indeed, that was my first way of implementing (in terms of writing an xtce
instance) it:

                    <RestrictionCriteria>
                        <CustomAlgorithm name="default" shortDescription="to be
used in case no other container matches">
                            <AlgorithmText
language="pseudo">default</AlgorithmText>
                        </CustomAlgorithm>
                    </RestrictionCriteria>

But I do not like this as the situation is IMO very common to all applications
dealing with ccsds packets (or by what way do you process an unknown CCSDS
packet, is it application built-in then?). Describing it this way is very hard
to describe in a recommendation and I doubt any application (besides the one
written by the author of the document) will process it intentionally.

Therefore I would prefer to recommend in the MB that in principle a packet is -
as you said - a non-abstract being restricted by use of a BaseContainer. But
there may exist one non-abstract packet without BaseContainer restriction that
shall be treated as default packet ... ?
Comment 6 Ludovic FAURE 2007-11-13 15:44:31 GMT 
I agree with Johannes about recommending the possible use of a default packet.
In fact, at CNES, most of the missions use CCSDS packets defined in a generic
and basic description by using existence conditions. So we will have only one
non-abstract container that will be the default packet. For me, this container
may not have a base container.
Comment 7 Kevin Rice 2007-11-13 16:29:47 GMT 
You are correct really that is not a very transferable way to do things.  The
problem is this below alone doesn't tell any processing system ENOUGH
information to process it:

<Container name="APacket">
   <EntryList>
       <ParameterRef name="APID"/>
       <ParameterRef name="LEN"/>
       <ParameterRef name="BODY"/>
   </EntryList>
</Container>

EXCEPT of course that the system is sophisticated enough to process CCSDS
headers, derive the length and then go from there -- sort of a "packet sniffer"
scenario.

Ultimately the only reason I put something in the MB for identifying packets in
the telemetry container area is because various people have asked me this very
question many times in the past:  "I don't see a 'packetList' in XTCE, how do I
determine which containers are packet descriptions?"

Soooo --- I tried to come up with a rule that makes sense... 

One problem is figuring not only WHICH containers are packets, but which
containers are NOT packets and should just be ignored by processing software...
as those containers will be part of other container definitions.

Again I am taking this from the position that I could receive an XTCE file from
Terma or CNES or ESA -- and with a very simple program I have written list out
the all the packets in each of these files.

Right now CNES describes their packets using an abstract container with a long
list of includeConditions for each individual packets which include OTHER
containers that have the variable portions of each individual packet.  They
call the principle abstract packet their "generic" packet.

Terma it sounds like would describe most of their packets more individually
with either Message or Restriction criteria, except there may be some which
have neither ...

How then does my simple software handle these two cases without KNOWING
something about the files being ingested beyond XTCE?

That is my basic question ...
Comment 8 Johannes Stamminger 2007-11-14 07:55:22 GMT 
Kevin, IMHO the CNES approach is not correct (as I just wrote to 409, sorry
again Ludovic).

Yesterday I thought about using Messages for identifying the packets. Mostly
because of the problem that more than one packet description might match a
packet (as in my example the concrete packet description and at least the
generic ccsds one, too). I thought about using the order of having referenced
the container from a MessageSet.

But with the current schema this is not possible - moreover I currently cannot
imagine any usecase for the current MessageSet definition.
Being able to define it explicitly like e.g.

<MessageSet>
  <Message name="packetA">
    <ContainerRef containerRef="packetADescription"/>
  </Message>
  <Message name="packetB">
    <ContainerRef containerRef="packetBDescription"/>
  </Message>
  ...
  <DefaultMessage name="ccsds">
    <ContainerRef containerRef="ccsdsDescription"/>
  </DefaultMessage>
</MessageSet>

I would have one - but this is regarding the schema ...


Concerning your short example container: of course, this is sufficient - and it
is needed/mandatory to process. At least if you want to process a stream of
ccsds packets that may contain packets not being described in the xtce document
relying on.
And I can image that this is not only valid for ccsds packets. I am not the
network expert but I'm quite sure that most protocols provide the length of the
packet somewhere within, I do not believe that much protocols defining the
packets of a fixed size (MIL-1553 might be one?). For all those protocols with
varying packet's length such a default packet describing the basic structure is
needed.
Comment 9 Kevin Rice 2007-11-14 13:35:12 GMT 
I think the problem of finding "all the packets" in the XTCE description is
typified by this example:

<Container name="tiny">
  <Entrylist>
     <ParameterRef name="len">
  <Entrylist>
</Container>
<Container name="tiny2">
 <Entrylist>
   <ParameterRef name="body">
 <Entrylist>
 <Basecontainer name="tiny"/>
</Container>

The question is -- do I have ONE or TWO packets?  As it stand now the MB says
"Tiny2" is the packet.

This is an extreme example but I think represents what is being discussed (???)

So the need is to mark a specific description as "default"?  In which case
"tiny" would represent that case with just its "header" being defined.
Comment 10 Kevin Rice 2007-11-14 13:45:54 GMT 
I think you've reflected your organization's needs within your XTCE documents
and that's fine.  Just like at some level Johannes is suggesting the need for a
"default" packet in XTCE and that reflects his experience with processing CCSDS
TLM.

One "problem" then with XTCE is an inability to enforce semantics -- we have
semantics for the various constructs and the MB tries to capture them.  Perhaps
the MB is not perfect in this regard as well and needs some improvement.

Implementing the same semantics ultimately means to me the ability to exchange
more broadly with others without everyone having to change their software.

As it stands right now if you send me CNES files (which you have done) -- my
software won't decompose that generic description into multiple concrete packet
descriptions.  BUT it would NOT be a huge effort to support it.

In my mind that means you have several options:

1- ignore some portions of MB and then know that folks using your XTCE files
will support your concept of the generic packet... 

2- go ahead and put the concrete packet information in, and ignore the
information for the purposes of your processing...
Comment 11 Ludovic FAURE 2007-11-15 09:33:37 GMT 
I understand that the most important point is  the interoperability of
different softwares that use XTCE. Because we need that our input XTCE file
describe a generic packet, we have a gateway that translate any input XTCE file
(with inheritance, message, etc..) in the form we expects and we are able to
process. 

I think our case is just a particular case where there is only one packet
definition in the description, isn't? I think this should be handle as default
behaviour where only one packet is defined in a XTCE file.

The problem is more about how can we restituate the packet identification that
we received from other agencies and that we dont process. I have an idea and i
would like to know if your softwares are able to handle it in the rigth way:
  For us  packet is identified by a set of fixed values (e.g if APID == 1000,
Service_Type == 1 and Service_subtype ==2 then it is packet1) and that's all.
All fields and containers are defined in the unique packet description with use
of include conditions. So if i said packet1 inheriths from myGenericPacket (or
message with reference to myGenericPacket ) with those restriction criteria, is
it what you expect to manage?
Comment 12 Kevin Rice 2007-11-15 12:59:14 GMT 
As to your last comment, yes I believe taking each includeCondition from the
"generic packet" (&removing), making it into a restrictionCriteria and then
subclassing the generic packet would do it, and is the same information.

So right now:

<container name="CNESGenericPacket" abstract="true"> <!-- short hand ... -->
    <EntryList>
       <parameterRef name="Header"/>
       <includeCondition name="Pkt1" Header.APID="3" Header.LEN="4"/>
       <includeCondition name="Pkt2" Header.APID="100" Header.LEN="87"/>
    </EntryList>
</container>
<container name="Pkt1">
  <!-- entrylist stuff -->
</container>
<container name="Pkt1">
  <!-- entrylist stuff -->
</container>

To this: (there are several possible variations to this approach depending on
exactly HOW you'd like to organize your containers -- this is one)

<container name="CNESGenericPacket" abstract="true"> <!-- short hand ... -->
    <EntryList>
       <parameterRef name="Header"/>
       <!-- includes are now restriction criteria below ... -->
    </EntryList>
</container>
<container name="Pkt1">
  <!-- entrylist stuff -->
  <RestrictionCriteria baseName="CNESGenericPacket" Header.APID="3"
Header.LEN="4"/>
</container>
<container name="Pkt1">
  <!-- entrylist stuff -->
  <RestrictionCriteria baseName="CNESGenericPacket" Header.APID="100"
Header.LEN="87"/>
</container>

Does that make sense?

Now -- besides that it still seems we need a good way to specify a "DEFAULT"
packet ... 

I'm thinking about it...
Comment 13 Ludovic FAURE 2007-11-15 13:53:41 GMT 
In fact, this is not really what i expected. I will try to illustrate what i
had in mind:

Original example is:

<container name="CNESGenericPacket" abstract="true"> <!-- short hand ... -->
  <EntryList>
     <parameterRef name="Header"/>
      <containerRef="Part1" includeCondition Header.APID="3" />
      <containerRef="Part2" includeCondition Header.APID="4" />
      <containerRef="Part3" includeCondition Header.APID >= 4 />
      <containerRef="Part4" includeCondition Header.APID="10" />
      <parameterRef name="Tail" includeCondition (Header.APID="3" ||
Header.APID="4") >
    </EntryList>
</container>
<container name="Part1">
  <!-- entrylist stuff -->
</container>
<container name="Part2">
  <!-- entrylist stuff -->
</container>
<container name="Part3">
  <!-- entrylist stuff -->
</container>
<container name="Part4">
  <!-- entrylist stuff -->
</container>

This is the generic packet definition. Now if i want to add information about a
packet identification i will associate to a given packet name, a table of fixed
field values. For instance, my packet1 can be defined like this, in addition to
the previous defintion:

<container/message name="packet1 ">
  <RestrictionCriteria baseName="CNESGenericPacket" Header.APID="3">
</container/message>

packet1 will contain: HEADER-part1-Tail

If packet2 contains:  HEADER-part3-part4 
It is written: 
<container/message name="packet2 ">
  <RestrictionCriteria baseName="CNESGenericPacket" Header.APID="10">
</container/message>

Are you able to process those packets? I think this is the kind of structure
that we will get at CNES from existent mission (packet identification can be
added manually becasue we dont have yet).
Comment 14 Kevin Rice 2007-11-15 13:58:41 GMT 
To me, yes -- it's not quite how i would do things but it allows you to keep
your structures intact and add a little info...

I'd like to draw up the UML but just looking at it -- technically yes, those
added containers from my software's perspective would be the concrete packets,
they'd extend the generic one and then of course have to run through all the
include conditions to construct they contents properly... (in fact its somewhat
duplicates info but that's ok)

I can't think at the moment why technically this should not be processable..

Description Ludovic FAURE 2007-10-31 17:38:22 GMT 
In the first example of the chapter 2.3.3.1, the refernce to the parameter used
the relative path: "PrimaryHeader.apid". The relative path for the space system
tree uses '/' to separate space systems, why not use '/' to separate container
from other container or parameter? By this way we will get an homogeneous way
to define paths in XTCE.

Comment 1 Kevin Rice 2007-10-31 20:33:09 GMT 
I'm a little confused by the comment so let me clarify what XTCE currently says
is ok within the specification -- and we can do from there.

Right now XTCE says that any reference outside of the current spacesystem to
another construct must use a "Path" to specify the location of the item being
referenced.  This would be true of Parameters, ParameterTypes, Containers,
Streams ... anything that has a "Reference" someplace in the schema.

(Actually the ANNOTATION says if its not found the name will be searched for in
progressively higher spacesystems.  And the Magenta Book says -- no in fact you
MUST put the Path there... That's another story -- but in either case we can
agree you MAY need to put Path info there to tell where the item is in
document)

But the way this works is the "path" portion only refers to the SpaceSystem
TREE through the NAME attribute associated with each SpaceSystem element, and
does not include any reserved names to specify exactly what portion of the
schema the reference refers to...  

Instead that information is found from within the Reference itself, where it
comes from and then depends on the concept as outlined in the "keys" at the
beginning of the schema to sort out the exact location.

For example XTCE does ALLOW this:

/MySpaceSystem/MySpaceSubSystem/BatV1

But we don't know just from this Ref that this refers to a Parameter.  Instead
we depend on the location of the Ref to tell us what it should be -- maybe this
is a parameterRef for example in the container area, so we would know it SHOULD
be in ParameterSet -- but which ONE?  In TelemetryMetaData or CommandMetaData? 
Well it COULD BE either -- in current XTCE, we allow either.

What this means is WE DO NOT ALLOW THIS:

/MySpaceSystem/MySpaceSubSystem/TelemetryMetaData/BatV1

Which would mean we have some reserved words in the path - of course this does
not completely gives us all the information either -- as we would not know just
by looking at the reference that BatV1 is in fact in ParameterSet.

Along those lines we do NOT allow this:

/MySpaceSystem/MySpaceSubSystem/TelemetryMetaData/ParameterSet/BatV1

So without that information in the Reference, we end up with strictly speaking
forming a common "reference name space" in certain parts of the schema, and
that is what the KEYS are supposed to help sort out.

Does this clear anything up?
Comment 2 Johannes Stamminger 2007-11-12 10:04:29 GMT 
IMHO there is a simple misunderstanding: the dot in "PrimaryHeader.type" is no
path indication. It refers to the way of specifying the primary header as in
the bottom of page 18, using an AggregateParameterType: the type is a Member of
the AggregateParameterType named CCSDSHeaderType.

For paths, regardless if pointing to other SpaceSystems, parameters or
containers, the slash is to be used.


BTW: is it allowed to write the affected parameterRef like
"./PrimaryHeader.type", too? With the dot now pointing to the current "element"
(*not* XML element but structural as described by KR in his comment before). It
is stated in the MB that path refs are UNIX like but this is not explicitly
mentioned.
Comment 3 Kevin Rice 2007-11-12 15:23:19 GMT 
At the moment the spec essentially says the names in the "path" refer to
spaceSystem names -- the attribute name in the spacesystem element.  Thus a
"./parameter" refer to the spaceSystem the parameter is defined in...

did I answer the question?
Comment 4 Johannes Stamminger 2007-11-12 15:28:29 GMT 
OK, I did not have a look to the spec for this, just to the MB. And there only
relative paths using '..' are used. The (btw: double, once relative path, once
Member of the referred type) meaning of '.' is not explained.
Comment 5 Kevin Rice 2007-11-12 15:32:21 GMT 
Ok I'll put something in the MB about it.  It's probably not explained really
in the spec very precisely but may use the term "unix-like" paths.  

So the "." and ".." would be similar in function to directory style filesystem
naming on unix/linux -- with caveat being everything is based on the
SpaceSystem 'name' attribute until the last part which would be a parameter,
container, metacommand, or metacommand/commandcontainer name, etc...

Description Kevin Rice 2007-11-12 20:29:42 GMT 
The SplinePoint element has an attribute called 'order' which seems to be a
hold over from an earlier version of this construct.  It should be ignored.

Description Ludovic FAURE 2007-12-12 07:02:01 GMT 
XTCE schema seems to allow only three size in bits for float encoding: 32, 64
and 128. Some existing missions at CNES, uses float parameters encoded on 48
bits and then this size is not correct against XTCE.
Comment 1 Kevin Rice 2008-05-01 21:41:23 BST 
This the same at 667 -- 48 bits is for 1750a, and some combos are probably not
legal given the attribute values for setting this,  further IEEE 80 bit
extended format is not supported either.

Description Kevin Rice 2008-03-04 22:57:09 GMT 
Expand NameReference concept to allow specifying items in precise locations
such as TelemetryMetaData, CommandMetaData, etc...