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 8886: repeat of arguments issue
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 8927: Xpath:
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 9204: CalibratorType
Issue 9206: CommandContainerType
Issue 9221: OnBoard Memory
Issue 9222: OnBoard Software
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 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...

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.

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.  

-- 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."

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) 

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

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.

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

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

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...

Description Kevin Rice 2008-03-20 19:03:47 GMT 
Two old comments are in the schema and should be removed.  They are:

Remove this comment: <!-- removed for CASTOR: default="PT0S" -->  line 1028

Remove this comment: <!-- default="00" (does not work with CASTOR 0.9.5.3) -->
line 2257

Description Kevin Rice 2008-03-20 19:05:29 GMT 
metaCommand@abstract has a default value of false, but *container@abstract does
not.

It should.

Description Kevin Rice 2008-03-20 19:07:03 GMT 
It has three attributes none of which are required and there are no defaults
for them -- result:  an empty DefaultSignificance can be set with NO
information.  Probably true for ContextSignificance as well. At least one
attribute should be required to avoid this.

Description Kevin Rice 2008-03-20 19:09:35 GMT 
MessageSet has an unrequired name.    This is not part of the NameReference
annotation and is inconsistent. I don't think this is used at all and should be
removed.

InputOutputTriggerAlgorithmType@triggerContainer is a NameType, should it be a NameReference?

InputOutputAlgorithm@thread optional boolean, should have default of false

Description Kevin Rice 2008-03-20 19:13:40 GMT 
toString/NumberFormat - element is required if toString is in use. Almost all
attributes are optional but defaults should be 

provided for "most common" likely format...

Description Kevin Rice 2008-03-20 19:13:40 GMT 
toString/NumberFormat - element is required if toString is in use. Almost all
attributes are optional but defaults should be 

provided for "most common" likely format...

Description Kevin Rice 2008-03-20 19:14:51 GMT 
*ArgumentType -- should be derived by extension from each *DataType (with no
additional extending info), autogenerators will then generate classes whose
class-names match the *ArgumentType names, instead of using the *DataType
names.

Description Kevin Rice 2008-03-20 19:37:07 GMT 
*Type/@initialValue - intialValue for the various types need to be more fully
spelled out.  StringType give no provision for UTF-8/UTF-16.  FloatType is a
double although encoding may generate 32-bit quantity... BinaryType may clip
actual storage size. Enumeration doesn't specify whether to use label or
value... Boolean:  possibly either '0' | '1' or 'oneStringValue' |
'zeroStringValue'.

FixedValueEntry@sizeInBits should be required

Description Kevin Rice 2008-03-27 22:13:54 GMT 
spelling typo

Description Kevin Rice 2008-05-01 21:19:28 BST 
These two items use a y=mx+b style adjuster to change the value given.  The
terminology should be aligned.

One implements it using attributes the other a seperate element, possible these
should be aligned as well.

FINALLY the default SLOPE (i.e. 'm') is 0 in one which is wrong -- adding an
empty LinearAdjust will result in a ZERO-ing of the retrieve dynamic value -- a
mistake.

Description Kevin Rice 2008-05-01 21:22:02 BST 
XTCE allows one to select in an attribute eithe MIL-1750A or IEEE-754 formats
and the bitsizes 32, 64, or 128.

This leaves out bitsize 48 for MIL-1750a -- a bug.

It also allows for combinations which are likely not legal:  MIL 64, or MIL
128.

Finally it misses IEEE extended double of 80 bits ...

Description Kevin Rice 2008-05-28 21:33:03 BST 
Various XTCE schema types for algorithms are not reflected in AlgorithmSet:
SimpleAlgorith, InputAlgorithm and InputOutputAlgorithm

Description Kevin Rice 2008-05-28 21:35:39 BST 
CustomAlgorithm which appears in many places in the schema should be a
namereference to AlgorithmSet.  To enforce the proper semantics the Ref should
"name" which algorithm type it referes to such as "InputAlgorithmRef" or
"InputOutputAlgorithmRef", etc...

Description Kevin Rice 2008-05-28 21:39:55 BST 
RestrictionCriteria seems incorrect for commands.  the value checked are
inserted to form the command, operators seem a little strange, maybe only '=='
makes sense, etc...

Description Kevin Rice 2008-05-28 21:41:50 BST 
OCL is an OMG standard that adds a constraint language to UML or any model.
It's related to RestrictionCriteria.  Would a specific XTCE Algorithm for OCL
be useful?

Description Kevin Rice 2008-05-28 21:43:30 BST 
Some autogenerators have problems with this -- name change.

Description Kevin Rice 2008-05-28 21:45:18 BST 
In EntryList, a containerRef that's to an abstract container has special
meaning.  perhaps it warrants it own entry to clear up the semantics.

Description Kevin Rice 2008-05-29 19:07:02 BST 
Confusing, suggest name change

Description Kevin Rice 2008-05-29 19:08:30 BST 
Should IndirectParameterEntry have a segment option?

Description Kevin Rice 2008-05-29 19:09:28 BST 
ChangeAlarmRates is confusing and ambigous due the fact the attribute setting
of which there are four are all optional but only certain combinations are
valid.  Valid combos are:  Change Per Sample, absolute change,  whereas Change
Per Second may be absolute change or percentage change.  Also absolute change
implies absolute value yet ranges allows for assymetric specification of +/-

Description Kevin Rice 2008-05-30 19:32:10 BST 
most organization use some outside alarms, not available now

Description Kevin Rice 2008-05-30 19:35:01 BST 
at least on old key is in the schema at the container area, remove any old ones

Description Kevin Rice 2009-03-18 22:16:51 GMT 
Doesn't really have enough info to identify parity bit location, and various
other aspects to completely describe it.  

CRC may be problematic as well

Description Kevin Rice 2009-06-04 18:07:59 BST 
Strictly speaking polynomials only have exponents in their terms which are
non-negative whole numbers.  the current construction specifies it as a double,
which is too broad...

Description Kevin Rice 2009-09-10 22:59:58 BST 
ByteOrderList is not valid for container and is part of the BinaryEncoding
element.

Ignore or remove from future version.

Description Kevin Rice 2009-09-10 23:02:26 BST 
Although the data type is a string and it will accept labels, because it has
the term "value" in the name, causes confusion.

The EnumeratedParameterType element currently does not support multiple context alarms, unlike the other ParameterType elements. 

This is probably because, on line 743 of the schema, the ContextAlarm element is not setting the maxOccurs attribute to "unbounded". Without this attribute, only one instance of the ContextAlarm element is allowed.

The EnumeratedParameterType element currently does not support multiple context alarms, unlike the other ParameterType elements. 

This is probably because, on line 743 of the schema, the ContextAlarm element is not setting the maxOccurs attribute to "unbounded". Without this attribute, only one instance of the ContextAlarm element is allowed.

Currently, it's possible to group ParameterTypes together through the AggregateParameterType. We would like to be able to add similar structure to individually declared Parameters. In other words, we would like a way to group Parameters together in a potentially nested, structured format.

It does not appear possible for the satellite factory to pass a minimum "observability" for parameters using XTCE.  It is possible I am mistaken here and a clarification would be sufficient.  This type of property is used when determining if a parameter has changed and damps out potential jitter in the measurements.

Clarify the reference point of absolute and relative bit positions in the container, when SequenceContainers are contained by other Containers.  This clarification should be added to the annotations in the schema

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

Possible answers:


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

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

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

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

Possible answers:

3) This one typically comes up when source material has adopted the C syntax for specifying strings as char arrays and its being used in a 'struct'.   In XTCE do not map char arrays that are strings to an 8-bit StringParameterType and then an ArrayParameterType that refers to it.   Instead calculate the length from the char array and make a StringParameterType that long to hold it and refer to that in the Member element.   To date even though this works (largely), it does not produce a happy face for the folks that have the original syntax.  The alternative is a complete re-working of XTCE's array description

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

Possible answers:

4) Since Parameter's @initialValue is a string, I don't see why comma delimited and {}  initializers can't be used similar to C, C++, Java, etc... these things should be pretty easy to parse.   Of course some extra checking will be needed to make sure the list of items fits into the data type and perhaps there's some sticky cases to be considered which would all need to written up and documented which is probably why the annotation says its not supported in the first place.

The XTCE element MetaCommand has a child element called VerifierSet.   Each of the Verifiers in the set are derived by schema-type extension except for the FailedVerifier.  This produces an inconsistency when using a tool like JAXB which maps the schema types to classes

element ParameterInstanceRefOperand in the MathOperationType has the flag but the "this" parameter doesn't say what the intent is in annotation or give the option of specifying whether it would be the raw or cooked (engineering converted) value.


So the XTCE 1.2 annotation could say "Use the calibrated value of this parameter in the calculation.  If the raw value for this parameter is desired, use the ParameterInstanceRefOperand to spell it out."

Which I think covers it... although it would be nice to have the attribute.

As previously discussed, the @order attribute of the <SplineCalibrator> relates to the fit funtion that is used for interpolation and extrapolation.


Interpolation is implied when the @order attribute is used.  Extrapolation has an explicit attribute.


Setting the order to zero effectively creates a "step" function, as the fit function is limited to zeroth order behavior.  First order behavior creates a linear function, otherwise called a "point to point".  Second order would be a quadratic, etc.


The schema allows only positive integers for the @order attribute.  This should be non-negative integer.

It would be convenient to add a shortDescription attribute to the Enumeration element for enumerated types.