${taskforce.name} Avatar
  1. OMG Task Force

XML Telemetric & Command Exchange Format 1.2 (XTCE) RTF — Closed Issues

  • Key: XTCE12
  • Issues Count: 247
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE12-502 Usage of readOnly is not clear per documentation XTCE 1.0 XTCE 1.2 Resolved closed
XTCE12-495 Command Container Changes Split In Two Resolutions XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-456 ValidRange element duplicated with ValidRangeSet in ArgumentTypeSet XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-485 Missed documentation updates from BitBucket subcommittee effort XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-478 Missed the CommandContainer updates to support Argument references XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-469 Missed DynamicValue in the PercentCompleteType from the proposal XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-464 Cleanup the last of the List returns XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-476 Missed optional descriptive elements on calibrators from proposed schema XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-472 Missing a number of Math Operators in latest proposal merge for XTCE 1.2. XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-512 More documentation updates from BitBucket subcommittee effort XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-510 Yet more documentation updates from BitBucket subcommittee effort XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-53 Combination Alarm XTCE 1.1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-1 TimeAssociation should be settable at the Container XTCE 1.0 XTCE 1.2 Resolved closed
XTCE12-114 Align ArgumentType and ParameterType construction XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-92 Derive ArgumentTypes by extension XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-119 AlarmType produces problem in JaxB XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-448 AbsoluteTimeParameterType Epoch is not always at midnight XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-454 LongDescriptionType as a complexType is unnecessary XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-490 Derived Issue: Update integer alarm definition types XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-489 Derived Issue: Update enumerated alarm definition types XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-488 Derived Issue: Update string alarm definition types XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-487 Derived Issue: Update base alarm definition types XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-467 Consolidate the proposals for ParameterProperties element XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-462 Cleanup unused/dead types in XTCE 1.2 proposed schema XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-459 Fix overuse of FixedIntegerValueType in proposal XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-457 Some primitive type intentions missed XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-482 Correct missed Argument Type updates for argumentRef versus parameterRef when calling out other parameters/arguments XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-397 MetaCommandStep argument assignment XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-29 Add normal alarm condition or alarm ranges XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-18 Improve FloatRangeType and IntegerRangeType XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-34 Only single instance of Alarm Condition/Range XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-50 Off Alarms XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-72 inside/outside alarms not supported XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-76 ChangeAlarmRates confusing and ambiguous XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-93 InputOutputAlgorithm@thread optional boolean, should have default of false XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-381 The ToString element used in Integer and Float types overlaps with Enumerated types XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-441 Mistake in previous resolution for addition of XInclude support XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-439 Error in unique keys fix in XTCE12-346 XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-431 Alternate approach to xs:positiveInteger and xs:nonNegativeInteger XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-395 Use of raw value for calibrator context selection XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-27 Fix annotation issues throughout schema XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-60 element ParameterInstanceRefOperand in the MathOperationType XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-61 The XTCE element MetaCommand has a child element called VerifierSet XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-67 Adding structure to Parameters XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-80 IndirectParameterEntry should have segment varient? XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-106 Explain interaction of dynamic value and segments, array lastEntryForThisArray XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-107 Generalize array type, add attribute for ROW or COL order XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-110 StringDataType UTF-8/CharacterWidth Issue XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-95 InputOutputTriggerAlgorithmType@triggerContainer is a NameType, should it be a NameReference? XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-124 MathOperator needs to be cleaned up XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-113 Autogenerator issue with schema type derivation XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-111 Unify metacommand/commandContainer and commandContainerSet/commandcontainer schema types XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-88 FixedValueEntry@sizeInBits should be required XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-400 ByteOrderList in XTCE 1.1 needs to be improved XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-15 Remove whitespace in selector xpath attribute XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-12 Improve CRCType Polynomial element XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-20 Variable length strings need optional maximum length designator XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-22 Repeat arguments XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-23 Fill argument XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-62 At the Parameter element, initial values for Array or Aggregates may not be set. XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-66 Member of an AggregateParameterType or AggregateArgumentType can't be an ArrayParameterType or ArrayArgumentType XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-59 Alarm count to enter alarm (minViolations), needs corresponding count to leave the alarm state XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-51 Change alarm XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-52 Digital Alarms XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-74 remove extraneous keys or uniq XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-75 ErroCorrectDetect -- Parity XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-71 In EnumerationAlarm, enumerationValue should called enumerationLabel XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-91 toString/NumberFormat needs default settings XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-133 Move array sizing to Parameter and Argument from container area XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-84 AlgorithmSet missing algorithms XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-87 FloatEncoding float formats -- MIL1750a, IEEE, bit size issues XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-7 toString/NumberFormat needs default settings XTCE 1.0 XTCE 1.2 Resolved closed
XTCE12-434 XTCE12-11 fix for name references did not work correctly XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-416 Member location within AggregateDataType XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-421 Provide specific type consequence level XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-33 Add ranges to enumeration list XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-17 Valid sizeInBits values for encoding="MILSTD_1750A" XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-19 StringAlarmList is required but it should be optional XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-31 Database of single SpaceSystem cannot designate a parameter to be within multiple systems XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-32 Add additional math operators to mathoperations XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-24 Add to or change way crc is specified XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-26 Add support for arbitary floating point XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-28 Error detection algorithm does not support XOR XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-10 Add xinclude to support ximport XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-45 Add raw units to ParameterType XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-49 Expand telemetry parameter data source attribute XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-68 Need a ParameterProperty for "observability" or "change only threshold" XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-56 Enum Alarm List should be optional XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-58 Bit extract feature needed in telemetry parameter XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-6 ContainerType issue XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-86 Time/Encoding@scale,@offset terminology vs DynamicValue/LinearAdjust XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-96 *Container@abstract should have default of false XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-103 size in bits of float encoding XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-8 Enumeration element could use an @shortDescription XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-16 Change NameType regex from zero or more to one or more characters XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-25 Range support in enumerated parameter type XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-11 Add regex to enforced syntax of NameReferences XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-13 Possible unused attribute in RepeatEntry XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-57 SplineCalibrator order attribute too restrictive XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-81 Condition has two elements with the same name, causes problems for some autogenerators XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-77 exponent attribute in Term element in PolynomialCalibrator should be non-negative integer XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-3 Package Identification: MessageKeys or Inheritance XTCE 1.0b1 XTCE 1.2 Closed; No Change closed
XTCE12-5 initialValue attribute only exists for a ParameterType or ArgumentType XTCE 1.0b1 XTCE 1.2 Closed; No Change closed
XTCE12-4 CommandContainer under the MetaCommand XTCE 1.0b1 XTCE 1.2 Closed; No Change closed
XTCE12-104 Add explanatory annotation that MetaCommand/CommandContainer is semantically similar to a Java Private Inner Class XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-108 Add name attribute to context alarms or calibrators XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-109 Key bugs XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-112 Move ValidRangeAppliesToCalibrated Attribute XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-94 MessageSet has unneeded attribute XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-97 DefaultSignicance element can have no content at all XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-118 TimeAssociation schema type is incorrect XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-121 PercentComplete in Verifiers needs clean up XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-99 Remove old comments XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-100 SplinePoint attribute order should be ignored (typo) XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-101 relative path in the parameterRef XTCE 1.1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-102 packet identification XTCE 1.1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-105 Use of the include conditions XTCE 1.1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-37 Add APID table list XTCE 1.1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-42 Add named width spacer to Container entry list XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-21 Add argument and fixed value entries to CommandContainerSet/CommandContainer XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-30 AlarmRanges cannot be defined based on raw values XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-44 Add title to parameter XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-69 EnumeratedParameterType does not support multiple context alarms XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-79 RelativeTimeType nomenclature conflicts with RelativeTimeParameterType XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-70 EnumeratedParameterType does not support multiple context alarms XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-2 CommandContainer issue XTCE 1.0b1 XTCE 1.2 Closed; No Change closed
XTCE12-90 *Type/@initialValue need clarifications XTCE 1.1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-132 Add ability to compare counters in IncludeCondition XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-136 Create RangeEnumeration Type XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-139 Clear Up Calibrated/Uncalibrated Values in Schema XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-115 Change UnitSet to simple String; change name XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-130 ContextAlarm not set to Inf Elements in EnumerationType XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-135 Fix ArgumentTypes child element or attributes that use the term Parameter, to Argument XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-35 Change all elements to top level schema types XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-36 Fix spelling of one/twosCompliment in IntegerDataEncoding XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-9 MetaCommandSet is incorrectly set to required XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-64 AggregateParameterType or AggregateArgumentType Member attribute 'typeRef' is vague XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-65 XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-117 Message/ContainRef should read ContainerRef XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-126 Put Alarms in Arguments; leaves Alarms in Command Parameters XTCE 1.1 XTCE 1.2 Closed; No Change closed
XTCE12-123 Change UnitSet to optional XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-125 Clean up Annotation Related to Verifiers XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-122 Clarify ContainerRef check in Verification area XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-127 ErrorDetectCorrect does not support Checksum XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-131 Label Missing in IntegerType/RangeEnumeration area XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-89 attribute twosCompliment should be twosComplement XTCE 1.1 XTCE 1.2 Duplicate or Merged closed
XTCE12-63 No short description or long description at the Member element of AggregateParameterType or AggregateArgumentType XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-150 OnBoard Software XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-148 OnBoard Memory XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-152 CalibratorType XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-151 Section: 7 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-155 MM-001 What missions need XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-188 HVM-004 Data Encoding definitions XTCE 1.0 XTCE 1.2 Resolved closed
XTCE12-153 MK-002 Type of element[MessageRef] is undefined XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-156 MP-001 Terminology XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-154 TH-001 Some Typos XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-158 Should use type[FixedFrameSyncStrategyType] in type [FixedFrameStreamType] XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-157 MK-005 Should use type[ContextCalibratorType] in … XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-160 V-003 Schema file identification XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-161 DC-013 Parameter encoding information XTCE 1.0 XTCE 1.2 Duplicate or Merged closed
XTCE12-159 MS-001 Missing page numbering XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-162 MS-003 Meaning not clear. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-141 8 - Add activity field to Alarms to indicate what the alarm will trigger XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-144 5 - Align XTCE and CCSDS Navigation Schemas (types) XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-142 3 - Use UML Instance diagrams for XTCE document example XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-145 - Add separate CalibratorSet to XTCE XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-147 1 - Support ability to describe redundant or complimentary data XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-149 CommandContainerType XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-166 DC-033 Line 6 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-173 DC-027 Line 3 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-174 DC-032 Line 3 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-178 DC-034 Line 10 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-175 DC-018 Line 10 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-182 DC-005 Figure XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-183 DC-026 Encoding area XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-168 DC-024 Line 6 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-167 DC-030 Line 5 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-169 DC-016 Line 4. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-171 DC-020 Line 4 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-170 DC-008 Line 4 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-177 DC-029 Line 1 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-180 DC-011 Figure text. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-137 Some sections/pages refer to the old (1.0) xsd version XTCE 1.1 XTCE 1.2 Resolved closed
XTCE12-138 9 - Add filtering of value threshold to maintain telemetry at certain rates XTCE 1.0 XTCE 1.2 Resolved closed
XTCE12-140 7 - Use UUIDs instead of current XTCE Referencing mechanism XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-146 6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-143 4 - Separate XTCE Schema into constituent parts XTCE 1.0 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-211 repeat of arguments issue XTCE 1.0b1 XTCE 1.2 Closed; Out Of Scope closed
XTCE12-209 XTCE issue: dimensionList in arrayParameterRef should be optional XTCE 1.0b1 XTCE 1.2 Duplicate or Merged closed
XTCE12-200 DC-004 "Philosophy", line 2 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-195 "Parameter Processing" box XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-198 "Foreword", line 2. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-196 "Foreword", 2nd last line XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-187 MK-007 Don't need element[ChangePerSecondAlarmConditions] XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-189 MS-009 De-calibration of cmd parameters? XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-186 DC-021 Assembly / dissembly of streams XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-190 DC-017 Assembly / dissembly information. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-163 MP-004 Logarithmic calibrations XTCE 1.0 XTCE 1.2 Duplicate or Merged closed
XTCE12-165 DC-009 Line 6 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-191 DC-028 ArgumentList XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-192 MK-010 All ParameterType and ArgumentType should have alarm element XTCE 1.0 XTCE 1.2 Duplicate or Merged closed
XTCE12-194 MK-003 A mistake of type[ContainerSegmentRefEntryType]'s annotation XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-172 DC-023 Line 3. XTCE 1.0 XTCE 1.2 Resolved closed
XTCE12-184 DC-025 Encoding information XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-185 MP-007 Dynamic telemetry check types XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-164 DC-012 Line 5 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-176 DC-010 Line 1 XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-179 MS-006 Footing of Figure 1 is missing. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-181 DC-015 Figure label. XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-38 Expand features to include common industry encodings in StreamsSet XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-40 Add switch entry to container entry list XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-43 Add gap entry to container entry list XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-46 Add variable to containers XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-41 Provide way to categorize all elements with @name into one or more groups XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-205 Xpath: XTCE 1.0b1 XTCE 1.2 Closed; No Change closed
XTCE12-207 command side unable to describe "packed commands" XTCE 1.0b1 XTCE 1.2 Closed; No Change closed
XTCE12-212 XTCE issue - add shortDescription to EntryList entries XTCE 1.0b1 XTCE 1.2 Resolved closed
XTCE12-202 "Command Processing" box XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-201 Spec too complex? XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-203 USE CCSDS examples how to use the standard XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-206 too much leeway how to use the standard XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-204 Propose that XCTE ( at this point ) will be limited to exchange data XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-197 Contents" XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-14 Type inheritance missing from Absolute and Relative time data types XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-48 Add ArgumentTypeSet to MetaCommand XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-47 Elevate annotation specifying time string formats to an attributes XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-54 Need support for mask alarm XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-82 Should RestrictionCriteria should be assignment not operators for Commanding? XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-193 AO-006 Additional examples (2) XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-199 MK-001 A mistake of attribute[messageRef]'s annotation XTCE 1.0 XTCE 1.2 Closed; No Change closed
XTCE12-208 lack of Union construct (MER + ASIST) XTCE 1.0b1 XTCE 1.2 Deferred closed
XTCE12-210 inability to describe sets of limits (alarms) and conversions (polynomials) XTCE 1.0b1 XTCE 1.2 Deferred closed
XTCE12-55 Re-architect XTCE alarm model XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-83 Add OCL specific Algorithm to XTCE XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-120 AbsoluteTime should have Alarms XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-129 Message/IncludeCondition/BaseContainer similarity XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-116 Add forward/reverse calibrator metadata XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-128 Checkwindow not tied to context XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-134 Move Alarms outside of Type Area XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-85 CustomAlgorithm should be "typed" reference to AlgorithmSet XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-98 Expand NameReference semantics XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-73 ByteOrderList is invalid for Containers XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-449 Cleanup Container EntryList element by deprecating IndirectParameterRefEntry XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-484 Re-evaluate the characterWidth attribute in String types XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-39 Add event message support XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-474 Missing a number of changes and enumerations in ErrorDetectCorrectType children XTCE 1.1 XTCE 1.2 Deferred closed
XTCE12-396 Calibrator selection using raw value XTCE 1.1 $issue.fixedSpecification.name Deferred closed

Issues Descriptions

Usage of readOnly is not clear per documentation

  • Key: XTCE12-502
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Documentation of readOnly attribute says the following per XTCE 1.1:
    A Parameter marked as 'readOnly' true is constant and non-settable

    It is not clear if this is intended to include "is constant". Constants should be defined per the dataSource property with a value of "constant" per the dataSource property's documentation.

    It is not clear if a readOnly item is settable by any means (even the C2 software itself) or is it just read-only to any clients or external applications.

    If it is intended to only influence clients and external applications, the documentation should be updated to be:
    A Parameter marked as 'readOnly' true is non-settable

  • Reported: XTCE 1.0 — Thu, 21 Dec 2017 20:36 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to improve the readOnly attribute annotation to be more clear

    We initially attempted to improve the documentation on the readOnly attribute in the ParameterProperties element. This did not quite meet the mark and the improvement was not as clear as it could be.

    Propose to modify the current XTCE 1.2 proposal annotation from:

    <attribute name="readOnly" type="boolean" use="optional" default="false">
    <annotation>
    <documentation xml:lang="en">A Parameter marked as 'readOnly' true is constant and non-settable. Note that a slight conceptual overlap exists here between the 'dataSource' and this attribute. When the 'dataSource' is 'constant', then 'readOnly' should be 'true'. Application implementations may choose to implicitly enforce this. Some implementations have both concepts of a Parameter that is settable and a Constant in a different part of the data model.</documentation>
    </annotation>
    </attribute>

    To an update documentation element of:

    <attribute name="readOnly" type="boolean" use="optional" default="false">
    <annotation>
    <documentation xml:lang="en">A Parameter marked as 'readOnly' true is non-settable by users and applications/services that do not represent the data source itself. Note that a slight conceptual overlap exists here between the 'dataSource' attribute and this attribute when the data source is 'constant'. For a constant data source, then 'readOnly' should be 'true'. Application implementations may choose to implicitly enforce this. Some implementations have both concepts of a Parameter that is settable or non-settable and a Constant in different parts of their internal data model.</documentation>
    </annotation>
    </attribute>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Command Container Changes Split In Two Resolutions

  • Key: XTCE12-495
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Due to size and readability issues, the fix for XTCE12-478 should be split into multiple resolutions. This issue has the second resolution attached.

  • Reported: XTCE 1.1 — Sat, 11 Nov 2017 15:35 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to better align the telemetry container annotation post-commanding improvements

    With the improvements on the commanding side for the CommandContainer EntryList element, the annotations can be factored back to the telemetry side to make the two of them consistent.

    Replace the existing EntryListType (shown first) with a replacement (shown second):

    <complexType name="EntryListType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Contains an ordered list of Entries. Used in Sequence Container</documentation>
    </annotation>
    <choice minOccurs="0" maxOccurs="unbounded">
    <element name="ParameterRefEntry" type="xtce:ParameterRefEntryType"/>
    <element name="ParameterSegmentRefEntry" type="xtce:ParameterSegmentRefEntryType"/>
    <element name="ContainerRefEntry" type="xtce:ContainerRefEntryType"/>
    <element name="ContainerSegmentRefEntry" type="xtce:ContainerSegmentRefEntryType"/>
    <element name="StreamSegmentEntry" type="xtce:StreamSegmentEntryType"/>
    <element name="IndirectParameterRefEntry" type="xtce:IndirectParameterRefEntryType"/>
    <element name="ArrayParameterRefEntry" type="xtce:ArrayParameterRefEntryType"/>
    </choice>
    </complexType>

    <complexType name="EntryListType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Contains an ordered list of Entries. Used in Sequence Container</documentation>
    </annotation>
    <choice minOccurs="0" maxOccurs="unbounded">
    <element name="ParameterRefEntry" type="xtce:ParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a Parameter to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ParameterSegmentRefEntry" type="xtce:ParameterSegmentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a portion of a Parameter to be a part of this container layout definition. This is used when the Parameter is reported in fractional parts in the container before being fully updated.</documentation>
    </annotation>
    </element>
    <element name="ContainerRefEntry" type="xtce:ContainerRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify the content of another Container to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ContainerSegmentRefEntry" type="xtce:ContainerSegmentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a portion of another Container to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="StreamSegmentEntry" type="xtce:StreamSegmentEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a portion of a Stream to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="IndirectParameterRefEntry" type="xtce:IndirectParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a previous (not last reported) value of a Parmeter to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ArrayParameterRefEntry" type="xtce:ArrayParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify an Array Type Parameter to be a part of this container layout definition when the Container does not populate the entire space of the Array contents. If the entire space of the Array is populated, a tolerant implementation will accept ParameterRefEntry also.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Replace the existing DynamicValueType (shown first) with a replacement (shown second):

    <complexType name="DynamicValueType">
    <annotation>
    <documentation xml:lang="en">Uses a parameter instance to obtain the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used </documentation>
    </annotation>
    <sequence>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType"/>
    <element name="LinearAdjustment" type="xtce:LinearAdjustmentType" minOccurs="0"/>
    </sequence>
    </complexType>

    <complexType name="DynamicValueType">
    <annotation>
    <documentation xml:lang="en">Uses a parameter instance to obtain the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used </documentation>
    </annotation>
    <sequence>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Retrieve the value by referencing the value of a Parameter.</documentation>
    </annotation>
    </element>
    <element name="LinearAdjustment" type="xtce:LinearAdjustmentType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A slope and intercept may be applied to scale or shift the value selected from the argument or parameter.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Replace the existing ComparisonListType (shown first) with a replacement (shown second):

    <complexType name="ComparisonListType">
    <annotation>
    <documentation xml:lang="en">All comparisons must be true</documentation>
    </annotation>
    <sequence>
    <element name="Comparison" type="xtce:ComparisonType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="ComparisonListType">
    <annotation>
    <documentation xml:lang="en">All comparisons must be true</documentation>
    </annotation>
    <sequence>
    <element name="Comparison" type="xtce:ComparisonType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">List of Comparison elements must all be true for the comparison to evaluate to true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Replace the existing ComparisonType (shown first) with a replacement (shown second):

    <complexType name="ComparisonType">
    <annotation>
    <documentation xml:lang="en">A simple ParameterInstanceRef to value comparison. The string supplied in the value attribute needs to be converted to a type matching the Parameter being compared to. Numerical values are assumed to be base 10 unless proceeded by 0x (hexadecimal), 0o (octal), or 0b (binary). The value is truncated to use the least significant bits that match the bit size of the Parameter being compared to.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterInstanceRefType">
    <attribute name="comparisonOperator" type="xtce:ComparisonOperatorsType" default="=="/>
    <attribute name="value" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML
    schema (xs) type specified for each XTCE type:
    integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean;
    binary=xs:hexBinary; enum=xs:string from EnumerationList;
    relative time= xs:duration; absolute time=xs:dateTime;
    array/aggregate=comma separated list of values inside curly braces {}.
    Supplied value must be within the ValidRange specified for the type and
    is a calibrated value.
    </documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ComparisonType">
    <annotation>
    <documentation xml:lang="en">A simple ParameterInstanceRef to value comparison. The string supplied in the value attribute needs to be converted to a type matching the Parameter being compared to. Numerical values are assumed to be base 10 unless proceeded by 0x (hexadecimal), 0o (octal), or 0b (binary). The value is truncated to use the least significant bits that match the bit size of the Parameter being compared to.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterInstanceRefType">
    <attribute name="comparisonOperator" type="xtce:ComparisonOperatorsType" default="==">
    <annotation>
    <documentation xml:lang="en">Operator to use for the comparison with the common equality operator as the default.</documentation>
    </annotation>
    </attribute>
    <attribute name="value" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time= xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the type.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Replace the existing BooleanExpressionType (shown first) with a replacement (shown second):

    <complexType name="BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">Holds an arbitrarily complex boolean expression</documentation>
    </annotation>
    <choice>
    <element name="Condition" type="xtce:ComparisonCheckType"/>
    <element name="ANDedConditions" type="xtce:ANDedConditionsType"/>
    <element name="ORedConditions" type="xtce:ORedConditionsType"/>
    </choice>
    </complexType>

    <complexType name="BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">Holds an arbitrarily complex boolean expression</documentation>
    </annotation>
    <choice>
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Condition elements describe a test similar to the Comparison element except that the parameters used have additional flexibility.</documentation>
    </annotation>
    </element>
    <element name="ANDedConditions" type="xtce:ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the parameters used are more flexible.</documentation>
    </annotation>
    </element>
    <element name="ORedConditions" type="xtce:ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the parameters used are more flexible.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Replace the existing ANDedConditionsType (shown first) with a replacement (shown second):

    <complexType name="ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe two or more conditions that are logically anded together. Conditions may be a mix of Condition and ORedCondition. See ORedConditionType and BooleanExpressionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Single conditional check.</documentation>
    </annotation>
    </element>
    <element name="ORedConditions" type="xtce:ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">Multiple conditional checks with a logical OR.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe two or more conditions that are logically anded together. Conditions may be a mix of Condition and ORedCondition. See ORedConditionType and BooleanExpressionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Condition elements describe a test similar to the Comparison element except that the parameters used have additional flexibility for the compare.</documentation>
    </annotation>
    </element>
    <element name="ORedConditions" type="xtce:ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the parameters used are more flexible and the and/or for multiple checks can be specified.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    Replace the existing ORedConditionsType (shown first) with a replacement (shown second):

    <complexType name="ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe two or more conditions that are logically ored together. Conditions may be a mix of Condition and ANDedCondition. See ORedConditionType and BooleanExpressionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Single conditional check.</documentation>
    </annotation>
    </element>
    <element name="ANDedConditions" type="xtce:ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">Multiple conditional checks with a logical AND.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe two or more conditions that are logically ored together. Conditions may be a mix of Condition and ANDedCondition. See ORedConditionType and BooleanExpressionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Condition elements describe a test similar to the Comparison element except that the parameters used have additional flexibility for the compare.</documentation>
    </annotation>
    </element>
    <element name="ANDedConditions" type="xtce:ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the parameters used are more flexible and the and/or for multiple checks can be specified.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    Replace the existing InputAlgorithmType (shown first) with a replacement (shown second):

    <complexType name="InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">A set of labeled inputs is added to the SimpleAlgorithmType</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:SimpleAlgorithmType">
    <sequence>
    <element name="InputSet" type="xtce:InputSetType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">A set of labeled inputs is added to the SimpleAlgorithmType</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:SimpleAlgorithmType">
    <sequence>
    <element name="InputSet" type="xtce:InputSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The InputSet describes the list of parameters that should be made available as input arguments to the algorithm.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Replace the existing DiscreteLookupListType (shown first) with a replacement (shown second):

    <complexType name="DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Lookup a value using the lookup list supplied. Use the first match found.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:DiscreteLookupType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Lookup a value using the lookup list supplied. Use the first match found.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:DiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Replace the existing DiscreteLookupType (shown first) with a replacement (shown second):

    <complexType name="DiscreteLookupType">
    <complexContent>
    <extension base="xtce:MatchCriteriaType">
    <attribute name="value" type="long" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="DiscreteLookupType">
    <annotation>
    <documentation xml:lang="en">Describe a discrete value lookup and the value associated when the lookup evaluates to true.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType">
    <attribute name="value" type="long" use="required">
    <annotation>
    <documentation xml:lang="en">Value to use when the lookup conditions are true.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Replace the existing MatchCriteriaType (shown first) with a replacement (shown second):

    <complexType name="MatchCriteriaType">
    <annotation>
    <documentation xml:lang="en">Contains either a simple Comparison, a ComparisonList, an arbitrarily complex BooleanExpression or an escape to an externally defined algorithm</documentation>
    </annotation>
    <choice>
    <element name="Comparison" type="xtce:ComparisonType">
    <annotation>
    <documentation xml:lang="en">A simple comparison check</documentation>
    </annotation>
    </element>
    <element name="ComparisonList" type="xtce:ComparisonListType"/>
    <element name="BooleanExpression" type="xtce:BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">An arbitrarily complex boolean expression</documentation>
    </annotation>
    </element>
    <element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">An escape to an externally defined algorithm</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    <complexType name="MatchCriteriaType">
    <annotation>
    <documentation xml:lang="en">Contains either a simple Comparison, a ComparisonList, an arbitrarily complex BooleanExpression or an escape to an externally defined algorithm</documentation>
    </annotation>
    <choice>
    <element name="Comparison" type="xtce:ComparisonType">
    <annotation>
    <documentation xml:lang="en">A simple comparison check involving a single test of a parameter value.</documentation>
    </annotation>
    </element>
    <element name="ComparisonList" type="xtce:ComparisonListType">
    <annotation>
    <documentation xml:lang="en">A series of simple comparison checks with an implicit 'and' in that they all must be true for the overall condition to be true.</documentation>
    </annotation>
    </element>
    <element name="BooleanExpression" type="xtce:BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">An arbitrarily complex boolean expression that has additional flexibility on the terms beyond the Comparison and ComparisonList elements.</documentation>
    </annotation>
    </element>
    <element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">An escape to an externally defined algorithm.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Replace the existing IntegerValueType (shown first) with a replacement (shown second):

    <complexType name="IntegerValueType">
    <annotation>
    <documentation xml:lang="en">Contains an Integer value; value may be provided directly or via the value in a parameter.</documentation>
    </annotation>
    <choice>
    <element name="FixedValue" type="long"/>
    <element name="DynamicValue" type="xtce:DynamicValueType"/>
    <element name="DiscreteLookupList" type="xtce:DiscreteLookupListType"/>
    </choice>
    </complexType>

    <complexType name="IntegerValueType">
    <annotation>
    <documentation xml:lang="en">Contains an Integer value; value may be provided directly or via the value in a parameter.</documentation>
    </annotation>
    <choice>
    <element name="FixedValue" type="long">
    <annotation>
    <documentation xml:lang="en">Use a fixed integer value.</documentation>
    </annotation>
    </element>
    <element name="DynamicValue" type="xtce:DynamicValueType">
    <annotation>
    <documentation xml:lang="en">Determine the value by interrogating an instance of a parameter.</documentation>
    </annotation>
    </element>
    <element name="DiscreteLookupList" type="xtce:DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Determine the value by interrogating an instance of a parameter and selecting a specified value based on tests of the value of that parameter.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

ValidRange element duplicated with ValidRangeSet in ArgumentTypeSet

  • Key: XTCE12-456
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    There appears to be a duplication mistake in the CommandMetaData ArgumentTypeSet. Two of the Argument Types (Integer and Float) have both a ValidRange element and a ValidRangeSet/ValidRange element.

    It is probably not necessary to have both. The single ValidRange should be fine. To define multiple ValidRanges introduces an opportunity for mismatch. If uncalibrated and calibrated ValidRange values exist, they should be converted to one or the other.

  • Reported: XTCE 1.1 — Sat, 3 Jun 2017 17:27 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to incorporate the consensus updates for ValidRangeSet in Argument types

    We recognize that the ValidRange and ValidRangeSet elements in the Float and Integer Argument Types in MetaCommand are confusing and seemingly redundant.

    To correct this, a consensus has arrived on removing the singleton ValidRange element and providing better explanation inside of ValidRangeSet on the usage, especially where multiple sequential ValidRange elements are present.

    The existing two types affected currently appear as:

    <complexType name="ArgumentFloatDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to FloatDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this argument.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentIntegerDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to IntegerDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this argument. This typically serves to bound user inputs.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:IntegerRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="xtce:FixedIntegerValueType">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    <attribute name="signed" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">Flag indicating if the engineering/calibrated data type used should support signed representation. This should not be confused with the encoding type for the raw value. The default is true.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    First step is to remove the definition of the ValidRange elements from the two type definitions above. This results in the following modification to be applied to the schema by replacing the existing types with:

    <complexType name="ArgumentFloatDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to FloatDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentIntegerDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to IntegerDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="initialValue" type="xtce:FixedIntegerValueType">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    <attribute name="signed" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">Flag indicating if the engineering/calibrated data type used should support signed representation. This should not be confused with the encoding type for the raw value. The default is true.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    The next step in the change is to update the annotations in the ValidFloatRangeSetType and ValidIntegerRangeSetType definitions. The existing definitions are:

    <complexType name="ValidFloatRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. Used to further bound argument values inside the ValidRange for the overall Data Type</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:FloatRangeType" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </complexType>

    <complexType name="ValidIntegerRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. Used to further bound argument values inside the ValidRange for the overall Data Type</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:IntegerRangeType" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </complexType>

    The updated definition below replaces the existing definition:

    <complexType name="ValidFloatRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. A single range is the most common, although it is possible to define multiple ranges when the valid values are not contiguous.</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:FloatRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A valid range constrains the whole set of possible values that could be encoded by the data type to a more "valid" or "reasonable" set of values. This should be treated as a boundary check in an implementation to validate the input or output value. Typically, only 1 range is used. In cases where multiple ranges are used, then the value is valid when it is valid in any of the provided ranges. Implementations may also use these ranges to enhance user interface displays and other visualization widgets as appropriate for the type.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </complexType>

    <complexType name="ValidIntegerRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. A single range is the most common, although it is possible to define multiple ranges when the valid values are not contiguous.</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:IntegerRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A valid range constrains the whole set of possible values that could be encoded by the data type to a more "valid" or "reasonable" set of values. This should be treated as a boundary check in an implementation to validate the input or output value. Typically, only 1 range is used. In cases where multiple ranges are used, then the value is valid when it is valid in any of the provided ranges. Implementations may also use these ranges to enhance user interface displays and other visualization widgets as appropriate for the type.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Missed documentation updates from BitBucket subcommittee effort

  • Key: XTCE12-485
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Several issues have noted that the XTCE 1.0 and 1.1 annotations have been lacking. Many of the updates were performed in conjunction with other issues that were more topic oriented to a particular area. In this, many elements/attributes/types did not require attention and as a result, did not get an opportunity to get annotation updates. In addition, some areas that were touched were done prior to reconciling the annotation updates.

  • Reported: XTCE 1.1 — Sat, 16 Sep 2017 15:30 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to include many annotation updates (part 1)

    This resolution includes the first set of annotation updates that covers most of the elements/attributes in the first few levels of depth in the XML. It is not proposed as a comprehensive and complete set, but appears to be ready for use/evaluation/voting.

    The list below is the typical method of showing the before and after of the XSD by type definition in the XSD. Each type is separated by a textual divider to make it easier to review.

    ================================================================================
    xs:schema element contents
    ================================================================================

    The root xml element in the schema is named schema. Immediately following is an "import" element and an "annotation" element. Propose to enhance the documentation here from:

    <annotation>
    <documentation xml:lang="en">This is the master schema for the OMG Space Domain Task Force XML Telemetric and Command data Exchange (XTCE) format.</documentation>
    </annotation>

    To:

    <annotation>
    <documentation xml:lang="en">This XML Schema Definition (XSD) defines syntax with concrete semantics for describing space or remote device telemetry and commanding in a platform and program independent manner.</documentation>
    </annotation>

    ================================================================================
    SpaceSystem element contents
    ================================================================================

    The first xs:element xml element in the schema is for the root SpaceSystem. Propose to enhance the documentation from:

    <annotation>
    <documentation xml:lang="en">The ROOT Element</documentation>
    </annotation>

    To:

    <annotation>
    <documentation xml:lang="en">The top-level SpaceSystem is the root element for the set of metadata necessary to monitor and command a space device, such as a satellite. A SpaceSystem defines a namespace. Metadata areas include: packets/minor frames layout, telemetry, calibration, alarm, algorithms, streams and commands. A SpaceSystem may have child SpaceSystems, forming a SpaceSystem tree. See SpaceSystemType.</documentation>
    </annotation>

    ================================================================================
    SpaceSystemType contents
    ================================================================================

    <complexType name="SpaceSystemType" mixed="false">
    <annotation>
    <documentation xml:lang="en">SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="Header" type="xtce:HeaderType" minOccurs="0"/>
    <element name="TelemetryMetaData" type="xtce:TelemetryMetaDataType" minOccurs="0"/>
    <element name="CommandMetaData" type="xtce:CommandMetaDataType" minOccurs="0"/>
    <element name="ServiceSet" type="xtce:ServiceSetType" minOccurs="0"/>
    <element ref="xtce:SpaceSystem" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="operationalStatus" type="token" use="optional"/>
    <attribute ref="xml:base"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="SpaceSystemType" mixed="false">
    <annotation>
    <documentation xml:lang="en">SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="Header" type="xtce:HeaderType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Header element contains optional descriptive information about this SpaceSystem or the document as a whole when specified at the root SpaceSystem.</documentation>
    </annotation>
    </element>
    <element name="TelemetryMetaData" type="xtce:TelemetryMetaDataType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element contains descriptions of the telemetry created on the space asset/device and sent to other data consumers.</documentation>
    </annotation>
    </element>
    <element name="CommandMetaData" type="xtce:CommandMetaDataType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element contains descriptions of the commands and their associated constraints and verifications that can be sent to the space asset/device.</documentation>
    </annotation>
    </element>
    <element name="ServiceSet" type="xtce:ServiceSetType" minOccurs="0"/>
    <element ref="xtce:SpaceSystem" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Additional SpaceSystem elements may be used like namespaces to segregate portions of the space asset/device into convenient groupings or may be used to specialize a product line generic SpaceSystem to a specific asset instance.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="operationalStatus" type="token" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional descriptive attribute for document owner convenience.</documentation>
    </annotation>
    </attribute>
    <attribute ref="xml:base"/>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    HeaderType contents
    ================================================================================

    <complexType name="HeaderType">
    <annotation>
    <documentation xml:lang="en">Schema for a Header record. A header contains general information about the system or subsystem.</documentation>
    </annotation>
    <sequence>
    <element name="AuthorSet" type="xtce:AuthorSetType" minOccurs="0"/>
    <element name="NoteSet" type="xtce:NoteSetType" minOccurs="0"/>
    <element name="HistorySet" type="xtce:HistorySetType" minOccurs="0"/>
    </sequence>
    <attribute name="version" type="string"/>
    <attribute name="date" type="string"/>
    <attribute name="classification" type="string" default="NotClassified"/>
    <attribute name="classificationInstructions" type="string"/>
    <attribute name="validationStatus" type="xtce:ValidationStatusType" use="required"/>
    </complexType>

    <complexType name="HeaderType">
    <annotation>
    <documentation xml:lang="en">Schema for a Header record. A header contains general information about the system or subsystem.</documentation>
    </annotation>
    <sequence>
    <element name="AuthorSet" type="xtce:AuthorSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The AuthorSet contains optional contact information for this document.</documentation>
    </annotation>
    </element>
    <element name="NoteSet" type="xtce:NoteSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The NoteSet contains optional technical information related to the content of this document.</documentation>
    </annotation>
    </element>
    <element name="HistorySet" type="xtce:HistorySetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The HistorySet contains optional evolutionary information for data contained in this document.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="version" type="string">
    <annotation>
    <documentation xml:lang="en">This attribute contains an optional version descriptor for this document.</documentation>
    </annotation>
    </attribute>
    <attribute name="date" type="string">
    <annotation>
    <documentation xml:lang="en">This attribute contains an optional date to be associated with this document.</documentation>
    </annotation>
    </attribute>
    <attribute name="classification" type="string" default="NotClassified">
    <annotation>
    <documentation xml:lang="en">This attribute contains optional classification status for use by programs for which that is applicable.</documentation>
    </annotation>
    </attribute>
    <attribute name="classificationInstructions" type="string">
    <annotation>
    <documentation xml:lang="en">This attribute contains an optional additional instructions attribute to be interpreted by programs that use this attribute.</documentation>
    </annotation>
    </attribute>
    <attribute name="validationStatus" type="xtce:ValidationStatusType" use="required">
    <annotation>
    <documentation xml:lang="en">This attribute contains a flag describing the state of this document in the evolution of the project using it.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    AuthorSetType contents
    ================================================================================

    <complexType name="AuthorSetType">
    <sequence>
    <element name="Author" type="xtce:AuthorType" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="AuthorSetType">
    <annotation>
    <documentation xml:lang="en">Describe an unordered collection of authors. See AuthorType.</documentation>
    </annotation>
    <sequence>
    <element name="Author" type="xtce:AuthorType" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Contains information about an author, maintainer, or data source regarding this document.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    AuthorType contents
    ================================================================================

    <simpleType name="AuthorType">
    <restriction base="string"/>
    </simpleType>

    <simpleType name="AuthorType">
    <annotation>
    <documentation xml:lang="en">Type definition that describes the format of the contents of the Author element.</documentation>
    </annotation>
    <restriction base="string"/>
    </simpleType>

    ================================================================================
    HistorySetType contents
    ================================================================================

    <complexType name="HistorySetType">
    <sequence>
    <element name="History" type="xtce:HistoryType" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="HistorySetType">
    <annotation>
    <documentation xml:lang="en">Describe an unordered collection of History elements. Usage is user defined. See HistoryType.</documentation>
    </annotation>
    <sequence>
    <element name="History" type="xtce:HistoryType" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Contains a history record related to the evolution of this document.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    NoteSetType contents
    ================================================================================

    <complexType name="NoteSetType">
    <sequence>
    <element name="Note" type="xtce:NoteType" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="NoteSetType">
    <annotation>
    <documentation xml:lang="en">Contains an unordered collection of Notes. Usage is user defined. See NoteType.</documentation>
    </annotation>
    <sequence>
    <element name="Note" type="xtce:NoteType" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Contains a program defined technical note regarding this document.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    AliasSetType contents
    ================================================================================

    <complexType name="AliasSetType">
    <annotation>
    <documentation xml:lang="en">Contains an unordered collection of Alias's</documentation>
    </annotation>
    <sequence>
    <element name="Alias" type="xtce:AliasType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="AliasSetType">
    <annotation>
    <documentation xml:lang="en">Contains an unordered collection of Alias elements to describe alternate names or IDs for this named item.</documentation>
    <appinfo>Applications should enforce uniqueness of individual nameSpace attribute values. Aliases are usually unique within the same nameSpace attribute value, depending on the physical meaning of that nameSpace. There are some cases where Alias values can be duplicated in a single nameSpace value.</appinfo>
    </annotation>
    <sequence>
    <element name="Alias" type="xtce:AliasType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">An alternate name, ID number, and sometimes flight software variable name in the code for this item.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    AliasType contents
    ================================================================================

    <complexType name="AliasType">
    <annotation>
    <documentation xml:lang="en">Used to contain an alias (alternate) name or ID for the object. For example, a parameter may have a mnemonic, an on-board id, and special IDs used by various ground software applications; all of these are alias's. Some ground system processing equipment has some severe naming restrictions on parameters (e.g., names must less then 12 characters, single case or integral id's only); their alias's provide a means of capturing each name in a "nameSpace".</documentation>
    </annotation>
    <attribute name="nameSpace" type="string" use="required"/>
    <attribute name="alias" type="string" use="required"/>
    </complexType>

    <complexType name="AliasType">
    <annotation>
    <documentation xml:lang="en">Used to contain an alias (alternate) name or ID for the object. For example, a parameter may have a mnemonic, an on-board id, and special IDs used by various ground software applications; all of these are alias's. Some ground system processing equipment has some severe naming restrictions on parameters (e.g., names must less then 12 characters, single case or integral id's only); their alias's provide a means of capturing each name in a "nameSpace". Note: the name is not reference-able (it cannot be used in a name reference substituting for the name of the item of interest). See NameDescriptionType.</documentation>
    </annotation>
    <attribute name="nameSpace" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Aliases should be grouped together in a "namespace" so that they can be switched in and out of data extractions. The namespace generally identifies the purpose of the alternate name, whether for software variable names, additional operator names, or whatever the purpose.</documentation>
    </annotation>
    </attribute>
    <attribute name="alias" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">The alternate name or ID to use. The alias does not have the restrictions that apply to name attributes. This is useful for capturing legacy identifiers for systems with unusual naming conventions. It is also useful for capturing variable names in software, amongst other things.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    AncillaryDataSetType contents
    ================================================================================

    <complexType name="AncillaryDataSetType">
    <sequence>
    <element name="AncillaryData" type="xtce:AncillaryDataType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="AncillaryDataSetType">
    <annotation>
    <documentation xml:lang="en">Describe an unordered collection of ancillary data. AncillaryData elements capture platform/program/implementation specific data about the parent element object that is non-standard and would not fit into the schema. See AncillaryDataType.</documentation>
    </annotation>
    <sequence>
    <element name="AncillaryData" type="xtce:AncillaryDataType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Optional list of AncillaryData elements associated with this item.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    AncillaryDataType contents
    ================================================================================

    <complexType name="AncillaryDataType">
    <annotation>
    <documentation xml:lang="en">Use for any other data associated with each named object. May be used to include administrative data (e.g., version, CM or tags) or potentially any MIME type. Data may be included or given as an href. </documentation>
    </annotation>
    <simpleContent>
    <extension base="string">
    <attribute name="name" type="string" use="required"/>
    <attribute name="mimeType" type="string" default="text/plain"/>
    <attribute name="href" type="anyURI"/>
    </extension>
    </simpleContent>
    </complexType>

    <complexType name="AncillaryDataType">
    <annotation>
    <documentation xml:lang="en">Use for any other data associated with a named item. May be used to include administrative data (e.g., version, CM or tags) or potentially any MIME type. Data may be included or given as an href.</documentation>
    </annotation>
    <simpleContent>
    <extension base="string">
    <attribute name="name" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Identifier for this Ancillary Data characteristic, feature, or data.</documentation>
    </annotation>
    </attribute>
    <attribute name="mimeType" type="string" default="text/plain">
    <annotation>
    <documentation xml:lang="en">Optional text encoding method for the element text content of this element. The default is "text/plain".</documentation>
    </annotation>
    </attribute>
    <attribute name="href" type="anyURI">
    <annotation>
    <documentation xml:lang="en">Optional Uniform Resource Identifier for this characteristic, feature, or data.</documentation>
    </annotation>
    </attribute>
    </extension>
    </simpleContent>
    </complexType>

    ================================================================================
    DescriptionType contents
    ================================================================================

    <complexType name="DescriptionType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An abstract type definition used as the base for NameDescriptionType or OptionalNameDescriptionType. The short description is intended to be used for quick "memory jogger" descriptions of the object. </documentation>
    </annotation>
    <sequence>
    <element name="LongDescription" type="xtce:LongDescriptionType" minOccurs="0"/>
    <element name="AliasSet" type="xtce:AliasSetType" minOccurs="0"/>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0"/>
    </sequence>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType" use="optional"/>
    </complexType>

    <complexType name="DescriptionType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Defines an abstract schema type used as basis for NameDescriptionType and OptionalNameDescriptionType, includes an attribute for a short description and an element for a longer unbounded description. This type also provides alias set and ancillary data set See AliasSetType and AncillaryDataSetType.</documentation>
    </annotation>
    <sequence>
    <element name="LongDescription" type="xtce:LongDescriptionType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional long form description to be used for explanatory descriptions of this item and may include HTML markup using CDATA. Long Descriptions are of unbounded length.</documentation>
    </annotation>
    </element>
    <element name="AliasSet" type="xtce:AliasSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to contain an alias (alternate) name or ID for this item. See AliasSetType for additional explanation.</documentation>
    </annotation>
    </element>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Use for any non-standard data associated with this named item. See AncillaryDataSetType for additional explanation.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional short description to be used for explanation of this item. It is recommended that the short description be kept under 80 characters in length.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    NameDescriptionType contents
    ================================================================================

    <complexType name="NameDescriptionType">
    <annotation>
    <documentation xml:lang="en">The type definition used by most elements that require a name with optional descriptions. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DescriptionType">
    <attribute name="name" type="xtce:NameType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="NameDescriptionType">
    <annotation>
    <documentation xml:lang="en">Defines a base schema type definition used by many other schema types throughout schema. Use it to describe a name with optional descriptions, aliases, and ancillary data. See NameType, LongDescriptionType, ShortDescriptionType, AliasSetType and AncillaryDataSetType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DescriptionType">
    <attribute name="name" type="xtce:NameType" use="required">
    <annotation>
    <documentation xml:lang="en">The name of this defined item. See NameType for restriction information.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    OptionalNameDescriptionType contents - core type special case of NameDescriptionType
    ================================================================================

    <complexType name="OptionalNameDescriptionType">
    <annotation>
    <documentation xml:lang="en">The type definition used by most elements that have an optional name with optional descriptions. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DescriptionType">
    <attribute name="name" type="xtce:NameType" use="optional"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="OptionalNameDescriptionType">
    <annotation>
    <documentation xml:lang="en">The type definition used by most elements that have an optional name with optional descriptions.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DescriptionType">
    <attribute name="name" type="xtce:NameType" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional name of this defined item. See NameType for restriction information.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    CommandMetaDataType contents
    ================================================================================

    <complexType name="CommandMetaDataType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Command Meta Data contains information about commands</documentation>
    </annotation>
    <sequence>
    <element name="ParameterTypeSet" type="xtce:ParameterTypeSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A list of parameter types</documentation>
    </annotation>
    </element>
    <element name="ParameterSet" type="xtce:ParameterSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Parameters referenced by MetaCommands. This Parameter Set is located here so that MetaCommand data can be built independently of TelemetryMetaData.</documentation>
    </annotation>
    </element>
    <element name="ArgumentTypeSet" type="xtce:ArgumentTypeSetType" minOccurs="0"/>
    <element name="MetaCommandSet" type="xtce:MetaCommandSetType" minOccurs="0"/>
    <element name="CommandContainerSet" type="xtce:CommandContainerSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Command Container defines the construction of a Command.</documentation>
    </annotation>
    </element>
    <element name="StreamSet" type="xtce:StreamSetType" minOccurs="0"/>
    <element name="AlgorithmSet" type="xtce:AlgorithmSetType" minOccurs="0"/>
    </sequence>
    </complexType>

    <complexType name="CommandMetaDataType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Describe command related metadata. Items defined in this area may refer to items defined in TelemetryMetaData. See TelemetryMetaDataType.</documentation>
    </annotation>
    <sequence>
    <element name="ParameterTypeSet" type="xtce:ParameterTypeSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A list of parameter types.</documentation>
    </annotation>
    </element>
    <element name="ParameterSet" type="xtce:ParameterSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Parameters referenced by MetaCommands. This Parameter Set is located here so that MetaCommand data can be built independently of TelemetryMetaData.</documentation>
    </annotation>
    </element>
    <element name="ArgumentTypeSet" type="xtce:ArgumentTypeSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A list of argument types. MetaCommand definitions can contain arguments and parameters. Arguments are user provided to the specific command definition. Parameters are provided/calculated/determined by the software creating the command instance. As a result, arguments contain separate type information. In some cases, arguments have different descriptive characteristics.</documentation>
    </annotation>
    </element>
    <element name="MetaCommandSet" type="xtce:MetaCommandSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A list of command definitions with their arguments, parameters, and container encoding descriptions.</documentation>
    </annotation>
    </element>
    <element name="CommandContainerSet" type="xtce:CommandContainerSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Similar to the ContainerSet for telemetry, the CommandContainerSet contains containers that can be referenced/shared by MetaCommand definitions.</documentation>
    </annotation>
    </element>
    <element name="StreamSet" type="xtce:StreamSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Contains an unordered set of Streams.</documentation>
    </annotation>
    </element>
    <element name="AlgorithmSet" type="xtce:AlgorithmSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Contains an unordered set of Algorithms.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Missed the CommandContainer updates to support Argument references

  • Key: XTCE12-478
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    In the commanding side of the schema, the CommandContainer heavily leverages the SequenceContainer from the telemetry side of the schema. This introduces an issue at several points where only parameters can be referenced when it is often more appropriate for arguments to be referenced.

    This change was done by the committee but got missed in the proposed updates.

  • Reported: XTCE 1.1 — Sun, 6 Aug 2017 16:33 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the missing updated to CommandContainer

    This resolution addresses the portion of the issue where the EntryList in CommandContainer does not sufficiently cover references to Arguments, in addition to Parameters. This requires creating a number of new types to add Argument specific support.

    First section of new types is needed to get up to creating an ArgumentSequenceEntryType derived from SequenceEntryType:

    Add new types to support the big upcoming ArgumentSequenceEntryType.

    First add ArgumentInstanceRefType and ArgumentInstanceType after the existing ArgumentAssignmentListType:

    <complexType name="ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">An argument instance is the name of an argument as the reference is always resolved locally to the metacommand.</documentation>
    </annotation>
    <attribute name="argumentRef" type="xtce:NameType" use="required">
    <annotation>
    <documentation xml:lang="en">Give the name of the argument. There is no path, this is a local reference.</documentation>
    </annotation>
    </attribute>
    <attribute name="useCalibratedValue" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">Typically the calibrated/engineering value is used and that is the default.</documentation>
    </annotation>
    </attribute>
    </complexType>

    <complexType name="ArgumentInstanceType">
    <annotation>
    <documentation xml:lang="en">The argument must be in the argument list of the metacommand. It's always just the name of the argument, not a true ref because the scope is always local to the metacommand its being used in.</documentation>
    </annotation>
    <sequence>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference to an argument instance value</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    After the ArgumentAssignmentType, add ArgumentComparisonType, ArgumentComparisonListType, ArgumentComparisonCheckType, and ArgumentDynamicValueType:

    <complexType name="ArgumentDynamicValueType">
    <annotation>
    <documentation xml:lang="en">Identical to DynamicValueType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <choice>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Retrieve the value by referencing the value of an Argument.</documentation>
    </annotation>
    </element>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Retrieve the value by referencing the value of a Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="LinearAdjustment" type="xtce:LinearAdjustmentType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A slope and intercept may be applied to scale or shift the value selected from the argument or parameter.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    <complexType name="ArgumentComparisonListType">
    <annotation>
    <documentation xml:lang="en">Identical to ComparisonListType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="Comparison" type="xtce:ArgumentComparisonType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">List of Comparison elements must all be true for the comparison to evaluate to true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    <complexType name="ArgumentComparisonType">
    <annotation>
    <documentation xml:lang="en">Identical to ComparisonType but supports argument instance references.</documentation>
    </annotation>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This parameter instance is being compared to the value in the parent element using the comparison defined there also.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This argument instance is being compared to the value in the parent element using the comparison defined there also.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="comparisonOperator" type="xtce:ComparisonOperatorsType" default="==">
    <annotation>
    <documentation xml:lang="en">Comparison operator to use with equality being the common default.</documentation>
    </annotation>
    </attribute>
    <attribute name="value" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </attribute>
    </complexType>

    <complexType name="ArgumentComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Identical to ComparisonCheckType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <sequence>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side parameter instance.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side argument instance.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="ComparisonOperator" type="xtce:ComparisonOperatorsType">
    <annotation>
    <documentation xml:lang="en">Comparison operator.</documentation>
    </annotation>
    </element>
    <choice>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side parameter instance. Parameter is assumed to be of the same type as the comparison Argument or Parameter.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side argument instance. Argument is assumed to be of the same type as the comparison Argument or Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="Value" type="string">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Now add the new ArgumentBooleanExpressionType, ArgumentANDedConditionsType, and ArgumentORedConditionsType following the above additions:

    <complexType name="ArgumentBooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">Identical to BooleanExpressionType but supports argument instance references.</documentation>
    </annotation>
    <choice>
    <element name="Condition" type="xtce:ArgumentComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Condition elements describe a test similar to the Comparison element except that the arguments/parameters used have additional flexibility.</documentation>
    </annotation>
    </element>
    <element name="ANDedConditions" type="xtce:ArgumentANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the arguments/parameters used are more flexible.</documentation>
    </annotation>
    </element>
    <element name="ORedConditions" type="xtce:ArgumentORedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the arguments/parameters used are more flexible.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    <complexType name="ArgumentANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">Identical to ANDedConditionsType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ArgumentComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Condition elements describe a test similar to the Comparison element except that the arguments/parameters used have additional flexibility for the compare.</documentation>
    </annotation>
    </element>
    <element name="ORedConditions" type="xtce:ArgumentORedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the arguments/parameters used are more flexible and the and/or for multiple checks can be specified.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentORedConditionsType">
    <annotation>
    <documentation xml:lang="en">Identical to ORedConditionsType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ArgumentComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Condition elements describe a test similar to the Comparison element except that the arguments/parameters used have additional flexibility for the compare.</documentation>
    </annotation>
    </element>
    <element name="ANDedConditions" type="xtce:ArgumentANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">This element describes tests similar to the ComparisonList element except that the arguments/parameters used are more flexible and the and/or for multiple checks can be specified.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    Prior to ArgumentListType, add the ArgumentInputAlgorithmType, ArgumentInputSetType, ArgumentDiscreteLookupListType, and ArgumentDiscreteLookupType

    <complexType name="ArgumentInputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Identical to InputAlgorithmType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:SimpleAlgorithmType">
    <sequence>
    <element name="InputSet" type="xtce:ArgumentInputSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The InputSet describes the list of arguments and/or parameters that should be made available as input arguments to the algorithm.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentInputSetType">
    <annotation>
    <documentation xml:lang="en">Identical to InputSetType but supports argument instance references.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    <element name="InputArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference an argument to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    <complexType name="ArgumentDiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Identical to DiscreteLookupListType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:ArgumentDiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from arguments and/or parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    <complexType name="ArgumentDiscreteLookupType">
    <annotation>
    <documentation xml:lang="en">Identical to ArgumentDiscreteLookupType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentMatchCriteriaType">
    <attribute name="value" type="long" use="required">
    <annotation>
    <documentation xml:lang="en">Value to use when the lookup conditions are true.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    After the ArgumentListType, add the new ArgumentMatchCriteriaType:

    <complexType name="ArgumentMatchCriteriaType">
    <annotation>
    <documentation xml:lang="en">Identical to MatchCriteriaType but supports argument instance references.</documentation>
    </annotation>
    <choice>
    <element name="Comparison" type="xtce:ArgumentComparisonType">
    <annotation>
    <documentation xml:lang="en">A simple comparison check involving a single test of an argument or parameter value.</documentation>
    </annotation>
    </element>
    <element name="ComparisonList" type="xtce:ArgumentComparisonListType">
    <annotation>
    <documentation xml:lang="en">A series of simple comparison checks with an implicit 'and' in that they all must be true for the overall condition to be true.</documentation>
    </annotation>
    </element>
    <element name="BooleanExpression" type="xtce:ArgumentBooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">An arbitrarily complex boolean expression that has additional flexibility on the terms beyond the Comparison and ComparisonList elements.</documentation>
    </annotation>
    </element>
    <element name="CustomAlgorithm" type="xtce:ArgumentInputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">An escape to an externally defined algorithm.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    After the existing IntegerValueType, add a new ArgumentIntegerValueType:

    <complexType name="ArgumentIntegerValueType">
    <annotation>
    <documentation xml:lang="en">Identical to IntegerValueType but supports argument instance references.</documentation>
    </annotation>
    <choice>
    <element name="FixedValue" type="long">
    <annotation>
    <documentation xml:lang="en">Use a fixed integer value.</documentation>
    </annotation>
    </element>
    <element name="DynamicValue" type="xtce:ArgumentDynamicValueType">
    <annotation>
    <documentation xml:lang="en">Determine the value by interrogating an instance of an argument or parameter.</documentation>
    </annotation>
    </element>
    <element name="DiscreteLookupList" type="xtce:ArgumentDiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Determine the value by interrogating an instance of an argument or parameter and selecting a specified value based on tests of the value of that argument or parameter.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    After the existing RepeatType, add a new ArgumentRepeatType:

    <complexType name="ArgumentRepeatType">
    <annotation>
    <documentation xml:lang="en">Identical to RepeatType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="Count" type="xtce:ArgumentIntegerValueType">
    <annotation>
    <documentation xml:lang="en">Value (either fixed or dynamic) that contains the count of repeated structures.</documentation>
    </annotation>
    </element>
    <element name="Offset" type="xtce:ArgumentIntegerValueType" minOccurs="0"/>
    </sequence>
    </complexType>

    After the existing LocationInContainerInBitsType, add a new ArgumentLocationInContainerInBitsType:

    <complexType name="ArgumentLocationInContainerInBitsType">
    <annotation>
    <documentation xml:lang="en">Identical to LocationInContainerInBitsType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentIntegerValueType">
    <attribute name="referenceLocation" type="xtce:ReferenceLocationType" default="previousEntry"/>
    </extension>
    </complexContent>
    </complexType>

    This uses the above stuff (dropped TimeAssociation from Argument entries - doesn't make sense):

    After the existing SequenceEntryType, add a new ArgumentSequenceEntryType:

    <complexType name="ArgumentSequenceEntryType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to a SequenceEntryType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="LocationInContainerInBits" type="xtce:ArgumentLocationInContainerInBitsType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The start bit 0 position for each container is local to the container, but does include space occupied by inherited containers. When a container is "included", as opposed to inherited, then the interpreting implementation takes into account the start bit position of the referring container when finally assembling the start bits for the post-processed entry content. The default start bit for any entry is 0 bits from the previous entry, making the content contiguous when this element is not used.</documentation>
    </annotation>
    </element>
    <element name="RepeatEntry" type="xtce:ArgumentRepeatType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">May be used when this entry repeats itself in the sequence container. When an entry repeats, it effectively specifies that the same entry is reported more than once in the container and has the same physical meaning. This should not be construed to be equivalent to arrays.</documentation>
    </annotation>
    </element>
    <element name="IncludeCondition" type="xtce:ArgumentMatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This entry will only be included in the sequence when this condition is true, otherwise it is always included. When the include condition evaluates to false, it is as if the entry does not exist such that any start bit interpretations cannot take into account the space that would have been occupied if this included condition were true.</documentation>
    </annotation>
    </element>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Ancillary data associated with this entry.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional short description for this entry element.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Add these Array Dimension types for the Array Argument after the existing DimensionType and DimensionListType:

    <complexType name="ArgumentDimensionType">
    <annotation>
    <documentation xml:lang="en">Identical to DimensionType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="StartingIndex" type="xtce:ArgumentIntegerValueType">
    <annotation>
    <documentation xml:lang="en">zero based index</documentation>
    </annotation>
    </element>
    <element name="EndingIndex" type="xtce:ArgumentIntegerValueType"/>
    </sequence>
    </complexType>

    <complexType name="ArgumentDimensionListType">
    <annotation>
    <documentation xml:lang="en">Identical to DimensionListType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="Dimension" type="xtce:ArgumentDimensionType" maxOccurs="unbounded">
    <annotation>
    <appinfo>For an ArrayParameterType of size N, their should be N Dimensions</appinfo>
    <appinfo>An array made up by multiple Entries should not have indexes that overlap, but should be continuous.</appinfo>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Now we get to the actual entries in the EntryList. Add these new entry types at the beginning of the packaging schema section, prior to the existing ArrayParameterRefEntryType:

    <complexType name="ArgumentArgumentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ArgumentRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="argumentRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ParameterRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentParameterSegmentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ParameterSegmentRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="order" type="xtce:PositiveLongType"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentContainerRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ContainerRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentContainerSegmentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ContainerSegmentRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="order" type="xtce:PositiveLongType"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentStreamSegmentEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to StreamRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="order" type="xtce:PositiveLongType"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentIndirectParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to IndirectParameterRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <sequence>
    <element name="ParameterInstance" type="xtce:ParameterInstanceRefType"/>
    </sequence>
    <attribute name="aliasNameSpace" type="string"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentArrayParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ArrayParameterRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <sequence minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Only used for subsetting an array. The array's true dimension sizes are set in the Type.</documentation>
    </annotation>
    <element name="DimensionList" type="xtce:DimensionListType">
    <annotation>
    <documentation xml:lang="en">The dimension here if used for subsetting must be less than the ones in the type. It's not a subset if its the same size.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="lastEntryForThisArrayInstance" type="boolean" default="false"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentArrayArgumentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to ArrayParameterRefEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <sequence minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Only used for subsetting an array. The array's true dimension sizes are set in the Type.</documentation>
    </annotation>
    <element name="DimensionList" type="xtce:ArgumentDimensionListType">
    <annotation>
    <documentation xml:lang="en">The dimension here if used for subsetting must be less than the ones in the type. It's not a subset if its the same size.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="argumentRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="lastEntryForThisArrayInstance" type="boolean" default="false"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentFixedValueEntryType">
    <annotation>
    <documentation xml:lang="en">Identical to FixedValueEntryType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentSequenceEntryType">
    <attribute name="name" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">An optional name for the fixed/constant field in the sequence.</documentation>
    </annotation>
    </attribute>
    <attribute name="binaryValue" type="hexBinary" use="required">
    <annotation>
    <documentation xml:lang="en">The fixed/constant value that should be encoded into the sequence. This value provided should have sufficient bit length to accomodate the size in bits. If the value is larger, the most significant unnecessary bits are dropped. The value provided should be in network byte order for encoding.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required">
    <annotation>
    <documentation xml:lang="en">The number of bits that this fixed/constant value should occupy in the sequence.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    FINALLY we update the CommandContainer definition to incorporate all of the above.

    Replace the existing definition of:

    <complexType name="CommandContainerEntryListType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Similar to an EntryList type but also may include command arguments or -as a convenience - fixed value entries.</documentation>
    </annotation>
    <choice minOccurs="0" maxOccurs="unbounded">
    <element name="ParameterRefEntry" type="xtce:ParameterRefEntryType"/>
    <element name="ParameterSegmentRefEntry" type="xtce:ParameterSegmentRefEntryType"/>
    <element name="ContainerRefEntry" type="xtce:ContainerRefEntryType"/>
    <element name="ContainerSegmentRefEntry" type="xtce:ContainerSegmentRefEntryType"/>
    <element name="StreamSegmentEntry" type="xtce:StreamSegmentEntryType"/>
    <element name="IndirectParameterRefEntry" type="xtce:IndirectParameterRefEntryType"/>
    <element name="ArrayParameterRefEntry" type="xtce:ArrayParameterRefEntryType"/>
    <element name="ArgumentRefEntry" type="xtce:ArgumentRefEntryType"/>
    <element name="ArrayArgumentRefEntry" type="xtce:ArrayParameterRefEntryType"/>
    <element name="FixedValueEntry" type="xtce:FixedValueEntryType"/>
    </choice>
    </complexType>

    With this new definition of:

    <complexType name="CommandContainerEntryListType">
    <annotation>
    <documentation xml:lang="en">Describe an entry list for a CommandContainer which is associated with a MetaCommand. The entry list for a MetaCommand CommandContainer element operates in a similar fashion as the entry list element for a SequenceContainer element. It adds fixed value and argument entries to the entry list not present in sequence containers. See MetaCommandType, CommandContainerType and EntryListType.</documentation>
    </annotation>
    <choice minOccurs="0" maxOccurs="unbounded">
    <element name="ParameterRefEntry" type="xtce:ArgumentParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a Parameter to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ParameterSegmentRefEntry" type="xtce:ArgumentParameterSegmentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a portion of a Parameter to be a part of this container layout definition. This is used when the Parameter is reported in fractional parts in the container before being fully updated.</documentation>
    </annotation>
    </element>
    <element name="ContainerRefEntry" type="xtce:ArgumentContainerRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify the content of another Container to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ContainerSegmentRefEntry" type="xtce:ArgumentContainerSegmentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a portion of another Container to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="StreamSegmentEntry" type="xtce:ArgumentStreamSegmentEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a portion of a Stream to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="IndirectParameterRefEntry" type="xtce:ArgumentIndirectParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify a previous (not last reported) value of a Parmeter to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ArrayParameterRefEntry" type="xtce:ArgumentArrayParameterRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify an Array Type Parameter to be a part of this container layout definition when the Container does not populate the entire space of the Array contents. If the entire space of the Array is populated, a tolerant implementation will accept ParameterRefEntry also.</documentation>
    </annotation>
    </element>
    <element name="ArgumentRefEntry" type="xtce:ArgumentArgumentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify an Argument to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    <element name="ArrayArgumentRefEntry" type="xtce:ArgumentArrayArgumentRefEntryType">
    <annotation>
    <documentation xml:lang="en">Specify an Array Type Argument to be a part of this container layout definition when the Container does not populate the entire space of the Array contents. If the entire space of the Array is populated, a tolerant implementation will accept ArgumentRefEntry also.</documentation>
    </annotation>
    </element>
    <element name="FixedValueEntry" type="xtce:ArgumentFixedValueEntryType">
    <annotation>
    <documentation xml:lang="en">Specify an immutable value to be a part of this container layout definition.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    To complete this resolution and maintain schema validity, it is now necessary to add the new BaseConditionsType before the existing BinaryType definition:

    <complexType name="BaseConditionsType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base type for boolean expression related elements that improves the mapping produced by data binding tools.</documentation>
    </annotation>
    </complexType>

    The new BaseConditionsType is already deployed with the ArgumentComparisonCheckType above, now apply it to the Parameter version of ComparisonCheckType and update the annotations to keep them consistent.

    <complexType name="ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Describe the comparison between the instance (value) of a parameter against either a specified value or another parameter instance.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <sequence>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side parameter instance.</documentation>
    </annotation>
    </element>
    <element name="ComparisonOperator" type="xtce:ComparisonOperatorsType">
    <annotation>
    <documentation xml:lang="en">Comparison operator.</documentation>
    </annotation>
    </element>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side parameter instance. Parameter is assumed to be of the same type as the comparison Parameter.</documentation>
    </annotation>
    </element>
    <element name="Value" type="string">
    <annotation>
    <documentation xml:lang="en">Right hand side value. Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Also replace the previous ANDedConditionsType for the same reason:

    <complexType name="ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe two or more conditions that are logically anded together. Conditions may be a mix of Condition and ORedCondition. See ORedConditionType and BooleanExpressionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Single conditional check.</documentation>
    </annotation>
    </element>
    <element name="ORedConditions" type="xtce:ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">Multiple conditional checks with a logical OR.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    And then the ORedConditionsType:

    <complexType name="ORedConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe two or more conditions that are logically ored together. Conditions may be a mix of Condition and ANDedCondition. See ORedConditionType and BooleanExpressionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <choice minOccurs="2" maxOccurs="unbounded">
    <element name="Condition" type="xtce:ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Single conditional check.</documentation>
    </annotation>
    </element>
    <element name="ANDedConditions" type="xtce:ANDedConditionsType">
    <annotation>
    <documentation xml:lang="en">Multiple conditional checks with a logical AND.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Missed DynamicValue in the PercentCompleteType from the proposal

  • Key: XTCE12-469
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The latest draft of the 1.2 schema included a change of the primitive type for the FixedValue element but did not include the DynamicValue element that was proposed.

  • Reported: XTCE 1.1 — Sun, 30 Jul 2017 18:21 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to merge in the DynamicValue to PercentCompleteType

    The proposed schema also includes a DynamicValue element. In order to incorporate this, the PercentCompleteType should be updated to replace this existing definition:

    <complexType name="PercentCompleteType">
    <annotation>
    <documentation>Describe a percentage complete that is fixed from 0 to 100, or as value from a parameter. See ExecutionVerifierType.</documentation>
    </annotation>
    <choice>
    <element name="FixedValue">
    <annotation>
    <documentation>0 to 100 percent</documentation>
    </annotation>
    <simpleType>
    <restriction base="double">
    <minInclusive value="0.0"/>
    <maxInclusive value="100.0"/>
    </restriction>
    </simpleType>
    </element>
    </choice>
    </complexType>

    With a new definition of:

    <complexType name="PercentCompleteType">
    <annotation>
    <documentation xml:lang="en">Describe a percentage complete that is fixed from 0 to 100, or as value from a parameter. See ExecutionVerifierType.</documentation>
    </annotation>
    <choice>
    <element name="FixedValue">
    <annotation>
    <documentation xml:lang="en">0 to 100 percent</documentation>
    </annotation>
    <simpleType>
    <restriction base="double">
    <minInclusive value="0.0"/>
    <maxInclusive value="100.0"/>
    </restriction>
    </simpleType>
    </element>
    <element name="DynamicValue" type="xtce:DynamicValueType">
    <annotation>
    <documentation xml:lang="en">Uses a parameter instance to obtain the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Cleanup the last of the List returns
  • Key: XTCE12-464
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    After approval of all the changes so far for XTCE 1.2, there are 5 cases where binding code generation results in List<Object> returns. These cases exist when multiple elements can be returned from a choice/sequence that do not share a common ancestor type.

  • Reported: XTCE 1.1 — Sun, 30 Jul 2017 15:32 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the List<Object> cases in the triggers

    The triggers within the TriggerSet can be slightly refactored in the schema to avoid the List<Object> mapping from the JAXB code generator.

    Add this new type between AlgorithmTextType and ChecksumType:

    <complexType name="BaseTriggerType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base type for the various triggers, purely to improve the mappings created by data binding compilers.</documentation>
    </annotation>
    </complexType>

    Modify existing trigger specific types to use extensions of the base type above on three of the complexType definitions. Replace the old definition (first) with the new one (second).

    Old:

    <complexType name="OnContainerUpdateTriggerType">
    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    </complexType>

    New:

    <complexType name="OnContainerUpdateTriggerType">
    <annotation>
    <documentation xml:lang="en">Describe a reference to container that triggers an event when the telemetry container referred to is updated (processed). See TriggerSetType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseTriggerType">
    <attribute name="containerRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Reference to the Container whose update/receipt triggers this algorithm to evaluate.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Old:

    <complexType name="OnPeriodicRateTriggerType">
    <attribute name="fireRateInSeconds" type="double" use="required"/>
    </complexType>

    New:

    <complexType name="OnPeriodicRateTriggerType">
    <annotation>
    <documentation xml:lang="en">Describe a periodic time basis to trigger an event. See TriggerSetType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseTriggerType">
    <attribute name="fireRateInSeconds" type="double" use="required">
    <annotation>
    <documentation xml:lang="en">The periodic rate in time in which this algorithm is triggered to evaluate.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Old:

    <complexType name="OnParameterUpdateTriggerType">
    <annotation>
    <documentation xml:lang="en">Names a parameter that upon change will start the execution of the algorithm. Holds a parameter reference name for a parameter that when it changes, will cause this algorithm to be executed.</documentation>
    </annotation>
    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    </complexType>

    New:

    <complexType name="OnParameterUpdateTriggerType">
    <annotation>
    <documentation xml:lang="en">Describe a reference to parameter that triggers an event when the telemetry parameter referred to is updated (processed) with a new value. See TriggerSetType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseTriggerType">
    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Reference to the Parameter whose update triggers this algorithm to evaluate.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next improve the annotations on the TriggerSet.

    Old:

    <complexType name="TriggerSetType">
    <annotation>
    <documentation xml:lang="en">A trigger is used to initiate the processing of some algorithm. A trigger may be based on an update of a Parameter or on a time basis. Triggers may also have a rate that limits their firing to a 1/rate basis.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="OnParameterUpdateTrigger" type="xtce:OnParameterUpdateTriggerType"/>
    <element name="OnContainerUpdateTrigger" type="xtce:OnContainerUpdateTriggerType"/>
    <element name="OnPeriodicRateTrigger" type="xtce:OnPeriodicRateTriggerType"/>
    </choice>
    <attribute name="name" type="string" use="optional"/>
    <attribute name="triggerRate" type="xtce:NonNegativeLongType" use="optional" default="1"/>
    </complexType>

    New:

    <complexType name="TriggerSetType">
    <annotation>
    <documentation xml:lang="en">A trigger is used to initiate the processing of some algorithm. A trigger may be based on an update of a Parameter, receipt of a Container, or on a time basis. Triggers may also have a maximum rate that limits how often the trigger can be invoked.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="OnParameterUpdateTrigger" type="xtce:OnParameterUpdateTriggerType">
    <annotation>
    <documentation xml:lang="en">This element instructs the trigger to invoke the algorithm evaluation when a Parameter update is received.</documentation>
    </annotation>
    </element>
    <element name="OnContainerUpdateTrigger" type="xtce:OnContainerUpdateTriggerType">
    <annotation>
    <documentation xml:lang="en">This element instructs the trigger to invoke the algorithm evaluation when a Container is received.</documentation>
    </annotation>
    </element>
    <element name="OnPeriodicRateTrigger" type="xtce:OnPeriodicRateTriggerType">
    <annotation>
    <documentation xml:lang="en">This element instructs the trigger to invoke the algorithm evaluation using a timer.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="name" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">Triggers may optionally be named.</documentation>
    </annotation>
    </attribute>
    <attribute name="triggerRate" type="xtce:NonNegativeLongType" use="optional" default="1">
    <annotation>
    <documentation xml:lang="en">This attribute is a maximum rate that constrains how quickly this trigger may evaluate the algorithm to avoid flooding the implementation. The default is once per second. Setting to 0 results in no maximum.</documentation>
    </annotation>
    </attribute>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Missed optional descriptive elements on calibrators from proposed schema

  • Key: XTCE12-476
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    It has been requested that the 3 core calibrator implementations: Spline, Polynomial, and MathOperation, provide some space for description and naming (optionally). In addition, annotation updates still need some refinement.

  • Reported: XTCE 1.1 — Sun, 6 Aug 2017 02:35 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the misses in the calibration elements (re-presented)

    The team members who originally opposed this resolution have decided that now this is okay. Re-presenting this resolution fix for ballot.

    The cleanest method to do this correction is to first add a new type, in this case named "BaseCalibratorType" that includes these extended descriptive elements and use that as the base for each of the specific calibrator elements.

    First step is to create the new "BaseCalibratorType" complexType just prior to the "CalibratorType" in the schema document:

    <complexType name="BaseCalibratorType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Supplies an optional non-reference-able name and short description for calibrators. Also includes an optional ancillary data for any special local flags, note that these may not necessarily transfer to another recipient of an instance document.</documentation>
    </annotation>
    <sequence>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional additional ancillary information for this calibrator/algorithm</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="name" type="string">
    <annotation>
    <documentation xml:lang="en">Optional name for this calibrator/algorithm</documentation>
    </annotation>
    </attribute>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType">
    <annotation>
    <documentation xml:lang="en">Optional description for this calibrator/algorithm</documentation>
    </annotation>
    </attribute>
    </complexType>

    Then update the CalibratorType to use this base type instead of inheriting from "OptionalNameDescriptionType" to cleanup some of the extra fluff in that element that would no longer be needed. Replace the existing "CalibratorType":

    <complexType name="CalibratorType">
    <annotation>
    <documentation xml:lang="en">Calibrators are normally used to convert to and from bit compacted numerical data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <choice>
    <element name="SplineCalibrator" type="xtce:SplineCalibratorType"/>
    <element name="PolynomialCalibrator" type="xtce:PolynomialCalibratorType"/>
    <element name="MathOperationCalibrator" type="xtce:MathOperationCalibratorType"/>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    With the following new definition for "CalibratorType":

    <complexType name="CalibratorType">
    <annotation>
    <documentation xml:lang="en">Describe a calibrator to transform a source data type raw/uncalibrated value (e.g. an integer count from a spacecraft) to an engineering unit/calibrated value for users (e.g. a float).</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseCalibratorType">
    <choice>
    <element name="SplineCalibrator" type="xtce:SplineCalibratorType">
    <annotation>
    <documentation xml:lang="en">Describes a calibrator in the form of a piecewise defined function</documentation>
    </annotation>
    </element>
    <element name="PolynomialCalibrator" type="xtce:PolynomialCalibratorType">
    <annotation>
    <documentation xml:lang="en">Describes a calibrator in the form of a polynomial function</documentation>
    </annotation>
    </element>
    <element name="MathOperationCalibrator" type="xtce:MathOperationCalibratorType">
    <annotation>
    <documentation xml:lang="en">Describes a calibrator in the form of a user/program/implementation defined function</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    Next, update the complexType "SplineCalibratorType". This is the simplest of the three changes for the concrete calibrators.

    Replace the old one:

    <complexType name="SplineCalibratorType">
    <annotation>
    <documentation xml:lang="en">A calibration type where a segmented line in a raw vs calibrated plane is described using a set of points. Raw values are converted to calibrated values by finding a position on the line corresponding to the raw value. The algorithm triggers on the input parameter.</documentation>
    </annotation>
    <sequence>
    <element name="SplinePoint" type="xtce:SplinePointType" minOccurs="2" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="order" type="xtce:NonNegativeLongType" default="1"/>
    <attribute name="extrapolate" type="boolean" default="false"/>
    </complexType>

    With this new implementation:

    <complexType name="SplineCalibratorType">
    <annotation>
    <documentation xml:lang="en">Describe a spline function for calibration using a set of at least 2 points. Raw values are converted to calibrated values by finding a position on the line corresponding to the raw value. The line may be interpolated and/or extrapolated as needed. The interpolation order may be specified for all the points and overridden on individual points. The algorithm triggers on the input parameter. See CalibratorType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseCalibratorType">
    <sequence>
    <element name="SplinePoint" type="xtce:SplinePointType" minOccurs="2" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describes a single point of the spline or piecewise function.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="order" type="xtce:NonNegativeLongType" default="1">
    <annotation>
    <documentation xml:lang="en">The interpolation order to apply to the overall spline function. Order 0 is no slope between the points (flat). Order 1 is linear interpolation. Order 2 would be quadratic and in this special case, 3 points would be required, etc.</documentation>
    </annotation>
    </attribute>
    <attribute name="extrapolate" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Extrapolation allows the closest outside point and the associated interpolation to extend outside of the range of the points in the spline function.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next update the PolynomialCalibratorType. Here we replace the implementation with a new one and also delete a now unused subtype:

    Existing implementation to replace:

    <complexType name="PolynomialCalibratorType">
    <annotation>
    <documentation xml:lang="en">A calibration type where a curve in a raw vs calibrated plane is described using a set of polynomial coefficients. Raw values are converted to calibrated values by finding a position on the curve corresponding to the raw value. The first coefficient belongs with the X^0 term, the next coefficient belongs to the X^1 term and so on. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:PolynomialType"/>
    </complexContent>
    </complexType>

    New implementation:

    <complexType name="PolynomialCalibratorType">
    <annotation>
    <documentation xml:lang="en">Describe a polynomial equation for calibration. This is a calibration type where a curve in a raw vs calibrated plane is described using a set of polynomial coefficients. Raw values are converted to calibrated values by finding a position on the curve corresponding to the raw value. The first coefficient belongs with the X^0 term, the next coefficient belongs to the X^1 term and so on. See CalibratorType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseCalibratorType">
    <sequence>
    <element name="Term" type="xtce:TermType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A single term in the polynomial function.</documentation>
    <appinfo>Generally only up to second order powers are reflexive. Implementations may limit the maximum number of terms supported.</appinfo>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Delete the now unused PolynomialType:

    <complexType name="PolynomialType">
    <annotation>
    <documentation xml:lang="en">A polynomial expression. For example: 3 + 2x</documentation>
    </annotation>
    <sequence>
    <element name="Term" type="xtce:TermType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    Updates to the MathOperationCalibratorType are last. Replace this existing implementation:

    <complexType name="MathOperationCalibratorType">
    <complexContent>
    <extension base="xtce:MathOperationType"/>
    </complexContent>
    </complexType>

    With this new implementation:

    <complexType name="MathOperationCalibratorType">
    <annotation>
    <documentation xml:lang="en">Describe a mathematical function for calibration where the mathematical function is defined using the MathOperationType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseCalibratorType">
    <choice maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a postfix (aka Reverse Polish Notation (RPN)) expression for mathematical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. For example, the stack, 4 8 /, would result as 0.5. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation>
    </annotation>
    <element name="ValueOperand" type="string">
    <annotation>
    <documentation xml:lang="en">Use a constant in the calculation.</documentation>
    </annotation>
    </element>
    <element name="ThisParameterOperand" type="string" fixed="">
    <annotation>
    <documentation xml:lang="en">Use the value of this parameter in the calculation. It is the calibrator's value only. If the raw value is needed, specify it explicitly using ParameterInstanceRefOperand. Note this element has no content.</documentation>
    </annotation>
    </element>
    <element name="Operator" type="xtce:MathOperatorsType">
    <annotation>
    <documentation xml:lang="en">All operators utilize operands on the top values in the stack and leaving the result on the top of the stack. Ternary operators utilize the top three operands on the stack, binary operators utilize the top two operands on the stack, and unary operators use the top operand on the stack.</documentation>
    </annotation>
    </element>
    <element name="ParameterInstanceRefOperand" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This element is used to reference the last received/assigned value of any Parameter in this math operation.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    Now, the MathOperationType no longer needs the content it contains. We retain it empty for inheritance by other more complex types.

    Replace the existing implementation:

    <complexType name="MathOperationType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Postfix (aka Reverse Polish Notation (RPN)) notation is used to describe mathmatical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="ValueOperand" type="double">
    <annotation>
    <documentation xml:lang="en">The element is used to represent a constant numeric value in the math operation.</documentation>
    </annotation>
    </element>
    <element name="ThisParameterOperand" type="string">
    <annotation>
    <documentation xml:lang="en">This element is a shortcut to represent the current parameter for which this math operation applies. It is shorter than using the ParameterInstanceRefOperand, which can also specify this current parameter, but in a longer form syntax.</documentation>
    </annotation>
    </element>
    <element name="ParameterInstanceRefOperand" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This element is used to reference the last received/assigned value of any Parameter in this math operation.</documentation>
    </annotation>
    </element>
    <element name="Operator" type="xtce:MathOperatorsType">
    <annotation>
    <documentation xml:lang="en">Binary operators: +, -, *, /, %, ^ operate on the top two values in the stack, leaving the result on the top of the stack. Unary operators: 1/x, x!, e^x, ln, log, and trigonometric operators operate on the top member of the stack also leaving the result on the top of the stack. 'ln' is a natural log where 'log' is a base 10 logarithm. Trigonometric operators use degrees. 'swap' swaps the top two members of the stack.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    With this new implementation:

    <complexType name="MathOperationType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Postfix (aka Reverse Polish Notation (RPN)) notation is used to describe mathmatical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MathOperationCalibratorType"/>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Missing a number of Math Operators in latest proposal merge for XTCE 1.2.

  • Key: XTCE12-472
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Previous issue resolution incorporated has some probably mistakes in the math operators.

    atan2 should have two arguments
    missing some new operators
    clarification of platform/language specific issues on some operators

  • Reported: XTCE 1.1 — Sat, 5 Aug 2017 16:46 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the misses in math operators

    This resolution proposes to replace the current proposed complexType MathOperatorsType with one that incorporates missing operators from the previous developed BitBucket schema. Additional appinfo is provided to assist in guiding implementers. An error was noted on the arguments for atan2() also.

    This is the replacement type definition:

    <simpleType name="MathOperatorsType">
    <annotation>
    <documentation xml:lang="en">Mathematical operators used in the math operation. Behavior of each operator on the stack is described using notation (before – after), where "before" represents the stack before execution of the operator and "after" represent the stack after execution.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="+">
    <annotation>
    <documentation xml:lang="en">addition (x1 x2 – x1+x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="-">
    <annotation>
    <documentation xml:lang="en">subtraction (x1 x2 – x1-x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="*">
    <annotation>
    <documentation xml:lang="en">multiplication (x1 x2 – x1*x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="/">
    <annotation>
    <documentation xml:lang="en">division (x1 x2 – x1/x2)</documentation>
    <appinfo>An undefined condition exists if x2 is 0</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="%">
    <annotation>
    <documentation xml:lang="en">modulo (x1 x2 – x3) Divide x1 by x2, giving the modulo x3</documentation>
    <appinfo>An undefined condition exists if x2 is 0. Implementations should verify modulo versus remainder behavior.</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="^">
    <annotation>
    <documentation xml:lang="en">power function (x1 x2 – x1**x2)</documentation>
    <appinfo>An undefined condition exists if an imaginary number is the result. Imaginary numbers are not supported</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="y^x">
    <annotation>
    <documentation xml:lang="en">reverse power function (x1 x2 – x2**x1)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="ln">
    <annotation>
    <documentation xml:lang="en">natural (base e) logarithm (x – ln)</documentation>
    <appinfo>An undefined condition exists if x is less than or equal to 0</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="log">
    <annotation>
    <documentation xml:lang="en">base-10 logarithm (x-- log)</documentation>
    <appinfo>An undefined condition exists if x is less than or equal to 0</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="e^x">
    <annotation>
    <documentation xml:lang="en">exponentiation (x – exp)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="1/x">
    <annotation>
    <documentation xml:lang="en">inversion (x – 1/x)</documentation>
    <appinfo>An undefined condition exists if x is less than 0</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="x!">
    <annotation>
    <documentation xml:lang="en">factorial (x – x!)</documentation>
    <appinfo>An undefined condition exists if x is less than 0</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="tan">
    <annotation>
    <documentation xml:lang="en">tangent (x – tan) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="cos">
    <annotation>
    <documentation xml:lang="en">cosine (x – cos) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="sin">
    <annotation>
    <documentation xml:lang="en">sine (x – sin) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="atan">
    <annotation>
    <documentation xml:lang="en">arctangent (x – atan) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="atan2">
    <annotation>
    <documentation xml:lang="en">arctangent (x1 x2 – atan2(x2, x1)) radians</documentation>
    <appinfo>An undefined condition exists if x1 and x2 are 0</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="acos">
    <annotation>
    <documentation xml:lang="en">arccosine (x – acos) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="asin">
    <annotation>
    <documentation xml:lang="en">arcsine (x – asin) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="tanh">
    <annotation>
    <documentation xml:lang="en">hyperbolic tangent (x – tanh)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="cosh">
    <annotation>
    <documentation xml:lang="en">hyperbolic cosine (x – cosh)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="sinh">
    <annotation>
    <documentation xml:lang="en">hyperbolic sine (x – sinh)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="atanh">
    <annotation>
    <documentation xml:lang="en">hyperbolic arctangent (x – atanh)</documentation>
    <appinfo>An undefined condition exists if x is outside the range [-1.0,+1.0]</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="acosh">
    <annotation>
    <documentation xml:lang="en">hyperbolic arccosine (x – acosh)</documentation>
    <appinfo>An undefined condition exists if n is less than 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="asinh">
    <annotation>
    <documentation xml:lang="en">hyperbolic arcsine (x – asinh)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="swap">
    <annotation>
    <documentation xml:lang="en">swap the top two stack items (x1 x2 – x2 x1)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="drop">
    <annotation>
    <documentation xml:lang="en">Remove top item from the stack (x – )</documentation>
    </annotation>
    </enumeration>
    <enumeration value="dup">
    <annotation>
    <documentation xml:lang="en">Duplicate top item on the stack (x – x x)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="over">
    <annotation>
    <documentation xml:lang="en">Duplicate top item on the stack (x1 x2 – x1 x2 x1)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="<<">
    <annotation>
    <documentation xml:lang="en">signed bitwise left shift (x1 x2 – x1 << x2)</documentation>
    <appinfo>Limitation from SEI INT13-C. Use bitwise operators only on unsigned operands</appinfo>
    </annotation>
    </enumeration>
    <enumeration value=">>">
    <annotation>
    <documentation xml:lang="en">signed bitwise right shift (x1 x2 – x1 >> x2)</documentation>
    <appinfo>Limitation from SEI INT13-C. Use bitwise operators only on unsigned operands</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="&">
    <annotation>
    <documentation xml:lang="en">bitwise and (x1 x2 – x1 & x2)</documentation>
    <appinfo>Limitation from SEI INT13-C. Use bitwise operators only on unsigned operands</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="|">
    <annotation>
    <documentation xml:lang="en">bitwise or (x1 x2 – x1 | x2)</documentation>
    <appinfo>Limitation from SEI INT13-C. Use bitwise operators only on unsigned operands</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="&&">
    <annotation>
    <documentation xml:lang="en">logical and (x1 x2 – x1 && x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="||">
    <annotation>
    <documentation xml:lang="en">logical or (x1 x2 – x1 || x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="!">
    <annotation>
    <documentation xml:lang="en">logical not (x1 x2 – x1 ! x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="abs">
    <annotation>
    <documentation xml:lang="en">absolute value (x1 – abs(x1))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="div">
    <annotation>
    <documentation xml:lang="en">Euclidean division quotient (x1 – div(x1))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="int">
    <annotation>
    <documentation xml:lang="en">integer part (x1 – int(x1))</documentation>
    </annotation>
    </enumeration>
    <enumeration value=">">
    <annotation>
    <documentation xml:lang="en">greater than x,y (x1 x2 – x1 > x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value=">=">
    <annotation>
    <documentation xml:lang="en">greater than or equal x,y (x1 x2 – x1 >= x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="<">
    <annotation>
    <documentation xml:lang="en">less than x,y (x1 x2 – x1 < x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="<=">
    <annotation>
    <documentation xml:lang="en">less than or equal x,y (x1 x2 – x1 <= x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="==">
    <annotation>
    <documentation xml:lang="en">equal x,y (x1 x2 – x1 == x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="!=">
    <annotation>
    <documentation xml:lang="en">not equal x,y (x1 x2 – x1 != x2)</documentation>
    <appinfo>The result of this can only be 0 or 1</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="min">
    <annotation>
    <documentation xml:lang="en">minimum of x,y (x1 x2 – min(x1, x2))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="max">
    <annotation>
    <documentation xml:lang="en">maximum of x,y (x1 x2 – max(x1, x2))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="xor">
    <annotation>
    <documentation xml:lang="en">Bitwise exclusive or (XOR) (x1 x2 – x1 xor x2)</documentation>
    <appinfo>Limitation from SEI INT13-C. Use bitwise operators only on unsigned operands</appinfo>
    </annotation>
    </enumeration>
    <enumeration value="~">
    <annotation>
    <documentation xml:lang="en">Bitwise not operation (x1 x2 – x1 ~ x2) The result of this can only be 0 or 1</documentation>
    <appinfo>Limitation from SEI INT13-C. Use bitwise operators only on unsigned operands</appinfo>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

More documentation updates from BitBucket subcommittee effort

  • Key: XTCE12-512
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Several issues have noted that the XTCE 1.0 and 1.1 annotations have been lacking. Many of the updates were performed in conjunction with other issues that were more topic oriented to a particular area. In this, many elements/attributes/types did not require attention and as a result, did not get an opportunity to get annotation updates. In addition, some areas that were touched were done prior to reconciling the annotation updates.

  • Reported: XTCE 1.1 — Tue, 30 Jan 2018 22:34 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose another set of annotation updates (part 2.1)

    This resolution includes the second set of annotation updates that covers most of the elements/attributes in the next few levels of depth in the XML. It is not proposed as a comprehensive and complete set, but appears to be ready for use/evaluation/voting.

    The list below is the typical method of showing the before and after of the XSD by type definition in the XSD. Each type is separated by a textual divider to make it easier to review.

    ================================================================================
    ParameterSetType contents
    ================================================================================

    <complexType name="ParameterSetType">
    <annotation>
    <documentation xml:lang="en">Used by both the TelemetryMetaData and the CommandMetaData components each may be built independently.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="Parameter" type="xtce:ParameterType">
    <annotation>
    <appinfo>Need to ensure that the named types actually exist</appinfo>
    </annotation>
    </element>
    <element name="ParameterRef" type="xtce:ParameterRefType">
    <annotation>
    <documentation xml:lang="en">Used to include a Parameter defined in another sub-system in this sub-system.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    <complexType name="ParameterSetType">
    <annotation>
    <documentation xml:lang="en">Describe an unordered collection of parameters where duplicates defined by the Parameter name attribute are invalid. The ParameterSet exists in both the TelemetryMetaData and the CommandMetaData element so that each may be built independently but from a single namespace. See TelemetryMetaDataType and CommandMetaDataType.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="Parameter" type="xtce:ParameterType">
    <annotation>
    <documentation xml:lang="en">Defines a named and typed Parameter.</documentation>
    <appinfo>Need to ensure that the named types actually exist</appinfo>
    </annotation>
    </element>
    <element name="ParameterRef" type="xtce:ParameterRefType">
    <annotation>
    <documentation xml:lang="en">Used to include a Parameter defined in another sub-system in this sub-system.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    ================================================================================
    MetaCommandSetType contents
    ================================================================================

    <complexType name="MetaCommandSetType">
    <annotation>
    <documentation xml:lang="en">A set of Command Definitions</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="MetaCommand" type="xtce:MetaCommandType">
    <annotation>
    <documentation xml:lang="en">All commands to be sent on this mission are listed here. In addition this area has verification and validation information</documentation>
    </annotation>
    <key name="ArgumentNameKey">
    <selector xpath="xtce:ArgumentList/*"/>
    <field xpath="@name"/>
    </key>
    </element>
    <element name="MetaCommandRef" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Used to include a MetaCommand defined in another sub-system in this sub-system.</documentation>
    </annotation>
    </element>
    <element name="BlockMetaCommand" type="xtce:BlockMetaCommandType"/>
    </choice>
    </complexType>

    <complexType name="MetaCommandSetType">
    <annotation>
    <documentation xml:lang="en">Describes an unordered collection of command definitions. Duplicates are invalid based on the name attribute of MetaCommand and BlockMetaCommand. See MetaCommandType and BlockMetaCommandType.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="MetaCommand" type="xtce:MetaCommandType">
    <annotation>
    <documentation xml:lang="en">All atomic commands to be sent on this mission are listed here. In addition this area has verification and validation information.</documentation>
    </annotation>
    <key name="ArgumentNameKey">
    <selector xpath="xtce:ArgumentList/*"/>
    <field xpath="@name"/>
    </key>
    </element>
    <element name="MetaCommandRef" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Used to include a MetaCommand defined in another sub-system in this sub-system.</documentation>
    </annotation>
    </element>
    <element name="BlockMetaCommand" type="xtce:BlockMetaCommandType">
    <annotation>
    <documentation xml:lang="en">Used to define a command that includes more than one atomic MetaCommand definition.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    ================================================================================
    SequenceContainerType contents - did not do anything with idlePattern - was not sure about that
    ================================================================================

    <complexType name="SequenceContainerType">
    <annotation>
    <documentation xml:lang="en">A list of raw parameters, parameter segments, stream segments, containers, or container segments. Sequence containers may inherit from other sequence containers; when they do, the sequence in the parent SequenceContainer is 'inherited' and if the location of entries in the child sequence is not specified, it is assumed to start where the parent sequence ended. Parent sequence containers may be marked as "abstract". The idle pattern is part of any unallocated space in the Container.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ContainerType">
    <sequence>
    <element name="EntryList" type="xtce:EntryListType"/>
    <element name="BaseContainer" type="xtce:BaseContainerType" minOccurs="0"/>
    </sequence>
    <attribute name="abstract" type="boolean" default="false"/>
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0x0"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="SequenceContainerType">
    <annotation>
    <documentation xml:lang="en">Describes the binary layout/packing of data and also related properties, including an entry list of parameters, parameter segments, array parameters, stream segments, containers, and container segments. Sequence containers may extend other sequence containers (see BaseContainerType). The parent container’s entries are placed before the entries in the child container forming one entry list. An inheritance chain may be formed using this mechanism, but only one entry list is being created. Sequence containers may be marked as "abstract", when this occurs an instance of it cannot itself be created. The idle pattern is part of any unallocated space in the container. See EntryListType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ContainerType">
    <sequence>
    <element name="EntryList" type="xtce:EntryListType">
    <annotation>
    <documentation xml:lang="en">List of item entries to pack/encode into this container definition.</documentation>
    </annotation>
    </element>
    <element name="BaseContainer" type="xtce:BaseContainerType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional inheritance for this container from another named container.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="abstract" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Abstract container definitions that are not instantiated, rather only used as bases to inherit from to create specialized container definitions.</documentation>
    </annotation>
    </attribute>
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0x0">
    <annotation>
    <documentation xml:lang="en">The idle pattern is part of any unallocated space in the container. This is uncommon.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    CommandContainerType contents
    ================================================================================

    <complexType name="CommandContainerType" mixed="false">
    <annotation>
    <documentation xml:lang="en">The Key = Command Op Code. Each MetaCommand may have one CommandContainer. The sequence may now contain command fields</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ContainerType">
    <sequence>
    <element name="EntryList" type="xtce:CommandContainerEntryListType"/>
    <element name="BaseContainer" type="xtce:BaseContainerType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="CommandContainerType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Describe a MetaCommand command container. The command container may contain arguments, parameters, other basic containers, and fixed values. Arguments are supplied by the user of a commanding application; parameters are supplied by the controlling system. Parameters and arguments map source data types to encodings. See MetaCommandType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ContainerType">
    <sequence>
    <element name="EntryList" type="xtce:CommandContainerEntryListType">
    <annotation>
    <documentation xml:lang="en">List of item entries to pack/encode into this container definition.</documentation>
    </annotation>
    </element>
    <element name="BaseContainer" type="xtce:BaseContainerType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">When a MetaCommand inherits/extends another MetaCommand, this references the CommandContainer from the BaseMetaCommand.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    BaseContainerType contents
    ================================================================================

    <complexType name="BaseContainerType">
    <sequence>
    <element name="RestrictionCriteria" type="xtce:RestrictionCriteriaType" minOccurs="0"/>
    </sequence>
    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    </complexType>

    <complexType name="BaseContainerType">
    <annotation>
    <documentation xml:lang="en">Describe a child/parent container inheritance relationship. Describe constraints with RestrictionCriteria, conditions that must be true for this container to be an extension of the parent container. A constraint can be used to convey the identifying features of the telemetry format such as the CCSDS application id or minor-frame id. See RestrictionCriteriaType and SequenceContainerType.</documentation>
    </annotation>
    <sequence>
    <element name="RestrictionCriteria" type="xtce:RestrictionCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Contains the conditions that must evaluate to true in order for this container to be an extension of the parent container.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="containerRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Reference to the container that this container extends.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    LocationInContainerInBitsType contents
    ================================================================================

    <complexType name="LocationInContainerInBitsType">
    <annotation>
    <documentation xml:lang="en">Addresses are relative to the container the entry is in. Zero is always the start of the container. If the container is an entry in another, the referring container's entry address is added to the one being referred to the compute addresses. For container inheritance, the root container starts at address zero.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:IntegerValueType">
    <attribute name="referenceLocation" type="xtce:ReferenceLocationType" default="previousEntry"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="LocationInContainerInBitsType">
    <annotation>
    <documentation xml:lang="en">Describe the absolute or relative bit location of an entry in a container. The "referenceLocation" attribute specifies the starting bit anchor. If no referenceLocation value is given, the entry is assumed to begin at the first bit position after the previous entry. Each container starts at bit 0, thus "containerStart" is an offset from 0. Negative container start bits are before the container and are implementation dependent – these should be flagged as likely errors. "containerEnd" is given as a positive offset from the end of the container, thus a container end of 0 is exactly at the end of the container. Negative container end addresses are after the container and are implementation dependent – these should be flagged as likely errors. Positive "previouEntry" values are offsets from the previous entry – zero (0) is the default which means it follows contiguously from the last occupied bit of the previous entry. A value of one means it is offset 1-bit from the previous entry, and a value of negative 1 (-1) means it overlaps the previous entry by one bit, and so forth. The "nextEntry" attribute value is proposed for deprecation and should be avoided. See SequenceEntryType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:IntegerValueType">
    <attribute name="referenceLocation" type="xtce:ReferenceLocationType" default="previousEntry">
    <annotation>
    <documentation xml:lang="en">Defines the relative reference used to interpret the start bit position. The default is 0 bits from the end of the previousEntry, which makes the entry contiguous.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    UnitType contents
    ================================================================================

    <complexType name="UnitType" mixed="true">
    <annotation>
    <documentation>Describe the exponent, factor, form, and description for a unit. The unit itself is in element Unit in UnitSet. See UnitSetType. The attributes are optional because different programs use this element in different ways, depending on vendor support.</documentation>
    </annotation>
    <attribute name="power" type="double" use="optional" default="1"/>
    <attribute name="factor" type="string" use="optional" default="1"/>
    <attribute name="description" type="string" use="optional">
    <annotation>
    <documentation>A description of the unit, which may be for expanded human readability or for specification of the nature/property of the unit. For example, meters per second squared is of a nature/property of acceleration.</documentation>
    </annotation>
    </attribute>
    <attribute name="form" type="xtce:UnitFormType" use="optional" default="calibrated"/>
    </complexType>

    <complexType name="UnitType" mixed="true">
    <annotation>
    <documentation xml:lang="en">Describe the exponent, factor, form, and description for a unit. The unit itself is in element Unit in UnitSet. See UnitSetType. The attributes are optional because different programs use this element in different ways, depending on vendor support.</documentation>
    </annotation>
    <attribute name="power" type="double" use="optional" default="1">
    <annotation>
    <documentation xml:lang="en">Optional attribute used in conjunction with the "factor" attribute where some programs choose to specify the unit definition with these machine processable algebraic features. For example, a unit text of "meters" may have a "power" attribute of 2, resulting "meters squared" as the actual unit. This is not commonly used. The most common method for "meters squared" is to use the text content of the Unit element in a form like "m^2".</documentation>
    </annotation>
    </attribute>
    <attribute name="factor" type="string" use="optional" default="1">
    <annotation>
    <documentation xml:lang="en">Optional attribute used in conjunction with the "power" attribute where some programs choose to specify the unit definition with these machine processable algebraic features. For example, a unit text of "meters" may have a "factor" attribute of 2, resulting "2 times meters" as the actual unit. This is not commonly used. The most common method for "2 times meters" is to use the text content of the Unit element in a form like "2*m".</documentation>
    </annotation>
    </attribute>
    <attribute name="description" type="xtce:ShortDescriptionType" use="optional">
    <annotation>
    <documentation xml:lang="en">A description of the unit, which may be for expanded human readability or for specification of the nature/property of the unit. For example, meters per second squared is of a nature/property of acceleration.</documentation>
    </annotation>
    </attribute>
    <attribute name="form" type="xtce:UnitFormType" use="optional" default="calibrated">
    <annotation>
    <documentation xml:lang="en">The default value "calibrated" is most common practice to specify units at the engineering/calibrated value, it is possible to specify an additional Unit element for the raw/uncalibrated value.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    UnitSetType contents
    ================================================================================

    <complexType name="UnitSetType">
    <sequence>
    <element name="Unit" type="xtce:UnitType" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="UnitSetType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of units that form a unit-expression. Units may be described for both calibrated/engineering values and also potentially uncalibrated/raw values. See UnitType.</documentation>
    </annotation>
    <sequence>
    <element name="Unit" type="xtce:UnitType" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe the exponent, factor, form, and description for a unit. The attributes are optional because different programs use this element in different ways, depending on vendor support.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    BaseMetaCommandType contents
    ================================================================================

    <complexType name="BaseMetaCommandType">
    <annotation>
    <documentation xml:lang="en">The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified.</documentation>
    </annotation>
    <sequence>
    <element name="ArgumentAssignmentList" type="xtce:ArgumentAssignmentListType" minOccurs="0"/>
    </sequence>
    <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required"/>
    </complexType>

    <complexType name="BaseMetaCommandType">
    <annotation>
    <documentation xml:lang="en">When specified, a BaseMetaCommand element identifies that this MetaCommand inherits (extends) another MetaCommand. It’s required ArgumentAssignmentList narrows or this command from the parent. This is typically used when specializing a generic MetaCommand to a specific MetaCommand. See MetaCommandType.</documentation>
    </annotation>
    <sequence>
    <element name="ArgumentAssignmentList" type="xtce:ArgumentAssignmentListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Argument Assignments specialize a MetaCommand or BlockMetaCommand when inheriting from another MetaCommand. General argument values can be restricted to specific values to further specialize the MetaCommand.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Reference to the MetaCommand definition that this MetaCommand extends.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    MetaCommandType contents
    ================================================================================

    <complexType name="MetaCommandType" mixed="false">
    <annotation>
    <documentation xml:lang="en">A type definition used as the base type for a CommandDefinition</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="BaseMetaCommand" type="xtce:BaseMetaCommandType" minOccurs="0"/>
    <element name="SystemName" type="string" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional. Normally used when the database is built in a flat, non-hierarchical format</documentation>
    </annotation>
    </element>
    <element name="ArgumentList" type="xtce:ArgumentListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand.</documentation>
    </annotation>
    </element>
    <element name="CommandContainer" type="xtce:CommandContainerType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Tells how to package this command</documentation>
    </annotation>
    </element>
    <element name="TransmissionConstraintList" type="xtce:TransmissionConstraintListType" minOccurs="0"/>
    <element name="DefaultSignificance" type="xtce:SignificanceType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Some Command and Control Systems may require special user access or confirmations before transmitting commands with certain levels. The level is inherited from the Base MetaCommand.</documentation>
    </annotation>
    </element>
    <element name="ContextSignificanceList" type="xtce:ContextSignificanceListType" minOccurs="0"/>
    <element name="Interlock" type="xtce:InterlockType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis.</documentation>
    </annotation>
    </element>
    <element name="VerifierSet" type="xtce:VerifierSetType" minOccurs="0"/>
    <element name="ParameterToSetList" type="xtce:ParameterToSetListType" minOccurs="0"/>
    <element name="ParametersToSuspendAlarmsOnSet" type="xtce:ParametersToSuspendAlarmsOnSetType" minOccurs="0"/>
    </sequence>
    <attribute name="abstract" type="boolean" default="false"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="MetaCommandType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Describe a command which consists of an abstract portion (MetaCommand) and an optional packaging portion (MetaCommand CommandContainer). An argument list is provided. MetaCommand may extend other MetaCommands and their CommandContainer may extend other CommandContainer or SequenceContainers. A MetaCommand’s CommandContainer is private except as referred to in BaseMetaCommand (they are not visible to other containers and cannot be used in an entry list). MetaCommands may also define various other behavioral aspects of a command such as command verifiers. See CommandContainerType, ArgumentListType, BaseMetaCommandType and BaseContainerType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="BaseMetaCommand" type="xtce:BaseMetaCommandType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional inheritance for this MetaCommand from another named MetaCommand.</documentation>
    </annotation>
    </element>
    <element name="SystemName" type="string" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional. Normally used when the database is built in a flat, non-hierarchical format. May be used by implementations to group MetaCommands together.</documentation>
    </annotation>
    </element>
    <element name="ArgumentList" type="xtce:ArgumentListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand, but may be referenced in inherited MetaCommand definitions, generally to apply Argument Assignments to the values.</documentation>
    </annotation>
    </element>
    <element name="CommandContainer" type="xtce:CommandContainerType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Tells how to package/encode this command definition in binary form.</documentation>
    </annotation>
    </element>
    <element name="TransmissionConstraintList" type="xtce:TransmissionConstraintListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">List of constraints to check when sending this command.</documentation>
    </annotation>
    </element>
    <element name="DefaultSignificance" type="xtce:SignificanceType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Some Command and Control Systems may require special user access or confirmations before transmitting commands with certain levels. The level is inherited from the Base MetaCommand.</documentation>
    </annotation>
    </element>
    <element name="ContextSignificanceList" type="xtce:ContextSignificanceListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Some Command and Control Systems may require special user access or confirmations before transmitting commands with certain levels. In addition to the default, Significance can be defined in contexts where it changes based on the values of parameters.</documentation>
    </annotation>
    </element>
    <element name="Interlock" type="xtce:InterlockType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis.</documentation>
    </annotation>
    </element>
    <element name="VerifierSet" type="xtce:VerifierSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Functional list of conditions/changes to check after sending this command to determine success or failure.</documentation>
    </annotation>
    </element>
    <element name="ParameterToSetList" type="xtce:ParameterToSetListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">List of parameters to set new values upon completion of sending this command.</documentation>
    </annotation>
    </element>
    <element name="ParametersToSuspendAlarmsOnSet" type="xtce:ParametersToSuspendAlarmsOnSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">List of parameters to suspend alarm processing/detection upon completion of sending this command.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="abstract" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Abstract MetaCommand definitions that are not instantiated, rather only used as bases to inherit from to create specialized command definitions.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    BlockMetaCommandType contents
    ================================================================================

    <complexType name="BlockMetaCommandType">
    <annotation>
    <documentation xml:lang="en">BlockMetaCommands are simply a list of individual MetaCommands that can be packaged up in a single BlockMetaCommand.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="MetaCommandStepList" type="xtce:MetaCommandStepListType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="BlockMetaCommandType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered grouping of MetaCommands into a list, duplicates are valid. The block contains argument values fully specified. See MetaCommandStepListType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="MetaCommandStepList" type="xtce:MetaCommandStepListType">
    <annotation>
    <documentation xml:lang="en">List of the MetaCommands to include in this BlockMetaCommand.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    MetaCommandStepListType contents
    ================================================================================

    <complexType name="MetaCommandStepListType">
    <sequence>
    <element name="MetaCommandStep" type="xtce:MetaCommandStepType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="MetaCommandStepListType">
    <annotation>
    <documentation xml:lang="en">Describe the list of MetaCommand definitions that form the block command. Contains an ordered list of MetaCommandSteps where each step is a MetaCommand with associated arguments, duplicates are valid. See BlockMetaCommandType.</documentation>
    </annotation>
    <sequence>
    <element name="MetaCommandStep" type="xtce:MetaCommandStepType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A MetaCommand with specific specified argument values to include in the BlockMetaCommand.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    CommandVerifierType contents
    ================================================================================

    <complexType name="CommandVerifierType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A command verifier is used to check that the command has been successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The CheckWindow is a time period where the verification must test true to pass.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <sequence>
    <choice>
    <element name="ComparisonList" type="xtce:ComparisonListType"/>
    <element name="ContainerRef" type="xtce:ContainerRefType">
    <annotation>
    <documentation xml:lang="en">When verification is a new instance the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet</documentation>
    </annotation>
    </element>
    <element name="ParameterValueChange" type="xtce:ParameterValueChangeType"/>
    <element name="CustomAlgorithm" type="xtce:InputAlgorithmType"/>
    <element name="BooleanExpression" type="xtce:BooleanExpressionType"/>
    <element name="Comparison" type="xtce:ComparisonType"/>
    </choice>
    <choice>
    <element name="CheckWindow" type="xtce:CheckWindowType"/>
    <element name="CheckWindowAlgorithms" type="xtce:CheckWindowAlgorithmsType"/>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="CommandVerifierType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A command verifier is used to check that the command has been successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The CheckWindow is a time period where the verification must test true to pass.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <sequence>
    <choice>
    <element name="ComparisonList" type="xtce:ComparisonListType">
    <annotation>
    <documentation xml:lang="en">Verification is a list of comparisons.</documentation>
    </annotation>
    </element>
    <element name="ContainerRef" type="xtce:ContainerRefType">
    <annotation>
    <documentation xml:lang="en">Verification is a new instance of the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet.</documentation>
    </annotation>
    </element>
    <element name="ParameterValueChange" type="xtce:ParameterValueChangeType">
    <annotation>
    <documentation xml:lang="en">Verification is a telemetry parameter value change on the ground. For example, a command counter.</documentation>
    </annotation>
    </element>
    <element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Verification is outside the scope of regular command and telemetry processing.</documentation>
    </annotation>
    </element>
    <element name="BooleanExpression" type="xtce:BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">Verification is a boolean expression of conditions.</documentation>
    </annotation>
    </element>
    <element name="Comparison" type="xtce:ComparisonType">
    <annotation>
    <documentation xml:lang="en">Verification is a single comparison.</documentation>
    </annotation>
    </element>
    </choice>
    <choice>
    <element name="CheckWindow" type="xtce:CheckWindowType">
    <annotation>
    <documentation xml:lang="en">Define a time window for checking for verification.</documentation>
    </annotation>
    </element>
    <element name="CheckWindowAlgorithms" type="xtce:CheckWindowAlgorithmsType">
    <annotation>
    <documentation xml:lang="en">Define a time window algorithmically for verification.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    IntegerDataEncodingType contents
    ================================================================================

    <complexType name="IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For all major encodings of integer data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0"/>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0"/>
    </sequence>
    <attribute name="encoding" type="xtce:IntegerEncodingType" default="unsigned"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="8"/>
    <attribute name="changeThreshold" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of
    the minimum change in value that is significant. This is used by some systems to
    limit the telemetry processing and/or recording requirements, such as for an
    analog-to-digital converter that dithers in the least significant bit. If the value
    is unspecified or zero, any change is significant.
    </documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For all major encodings of integer data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when no Context Calibrators are provided or evaluate to true, based on their MatchCriteria.</documentation>
    </annotation>
    </element>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when a MatchCriteria evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="encoding" type="xtce:IntegerEncodingType" default="unsigned">
    <annotation>
    <documentation xml:lang="en">Specifies integer numeric value to raw encoding method, with the default being "unsigned".</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="8">
    <annotation>
    <documentation xml:lang="en">Number of bits to use for the raw encoding, with 8 being the default.</documentation>
    </annotation>
    </attribute>
    <attribute name="changeThreshold" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation xml:lang="en">A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements, such as for an analog-to-digital converter that dithers in the least significant bit. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    FloatDataEncodingType contents
    ================================================================================

    <complexType name="FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For common encodings of floating point data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0"/>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0"/>
    </sequence>
    <attribute name="encoding" type="xtce:FloatEncodingType" default="IEEE754_1985"/>
    <attribute name="sizeInBits" type="xtce:FloatEncodingSizeInBitsType" default="32"/>
    <attribute name="changeThreshold" type="double" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements. If the value is unspecified or zero, any change is significant.
    </documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For common encodings of floating point data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when no Context Calibrators are provided or evaluate to true, based on their MatchCriteria.</documentation>
    </annotation>
    </element>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when a MatchCriteria evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="encoding" type="xtce:FloatEncodingType" default="IEEE754_1985">
    <annotation>
    <documentation xml:lang="en">Specifies real/decimal numeric value to raw encoding method, with the default being "IEEE754_1985".</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatEncodingSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Number of bits to use for the float raw encoding method, with 32 being the default. Not every number of bits is valid for each encoding method.</documentation>
    <appinfo>Verify the number of bits for encoding is valid for the encoding method.</appinfo>
    </annotation>
    </attribute>
    <attribute name="changeThreshold" type="double" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    ValueEnumerationType contents
    ================================================================================

    <complexType name="ValueEnumerationType">
    <annotation>
    <documentation>Describe a value and an associated string label, see EnumerationListType.</documentation>
    </annotation>
    <attribute name="value" type="long" use="required"/>
    <attribute name="maxValue" type="long">
    <annotation>
    <documentation>If max value is given, the label maps to a range where value is less than or equal to maxValue. The range is inclusive.</documentation>
    </annotation>
    </attribute>
    <attribute name="label" type="string" use="required"/>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType"/>
    </complexType>

    <complexType name="ValueEnumerationType">
    <annotation>
    <documentation xml:lang="en">Describe a value and an associated string label, see EnumerationListType.</documentation>
    </annotation>
    <attribute name="value" type="long" use="required">
    <annotation>
    <documentation xml:lang="en">Numeric raw/uncalibrated value to associate with a string enumeration label.</documentation>
    </annotation>
    </attribute>
    <attribute name="maxValue" type="long">
    <annotation>
    <documentation xml:lang="en">If max value is given, the label maps to a range where value is less than or equal to maxValue. The range is inclusive.</documentation>
    </annotation>
    </attribute>
    <attribute name="label" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">String enumeration label to apply to this value definition in the enumeration.</documentation>
    </annotation>
    </attribute>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType">
    <annotation>
    <documentation xml:lang="en">An optional additional string description can be specified for this enumeration label to provide extended information if desired.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    TermType contents - for polynomials
    ================================================================================

    <complexType name="TermType">
    <annotation>
    <documentation xml:lang="en">A term in a polynomial expression. </documentation>
    </annotation>
    <attribute name="coefficient" type="double" use="required"/>
    <attribute name="exponent" type="xtce:NonNegativeLongType" use="required"/>
    </complexType>

    <complexType name="TermType">
    <annotation>
    <documentation xml:lang="en">A term in a polynomial expression.</documentation>
    </annotation>
    <attribute name="coefficient" type="double" use="required">
    <annotation>
    <documentation xml:lang="en">The coefficient in a single term of a polynomial expression.</documentation>
    </annotation>
    </attribute>
    <attribute name="exponent" type="xtce:NonNegativeLongType" use="required">
    <annotation>
    <documentation xml:lang="en">The exponent in a single term of a polynomial expression. Should negative exponents be required, use a Math Calibrator style of definition for this type.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    SplinePointType contents
    ================================================================================

    <complexType name="SplinePointType">
    <annotation>
    <documentation xml:lang="en">a spline is a set on points from which a curve may be drawn to interpolate raw to calibrated values</documentation>
    </annotation>
    <attribute name="order" type="xtce:NonNegativeLongType" default="1"/>
    <attribute name="raw" type="double" use="required"/>
    <attribute name="calibrated" type="double" use="required"/>
    </complexType>

    <complexType name="SplinePointType">
    <annotation>
    <documentation xml:lang="en">A spline, or piecewise defined function, is a set on points from which a curve may be drawn to interpolate raw to calibrated values</documentation>
    </annotation>
    <attribute name="order" type="xtce:NonNegativeLongType" default="1">
    <annotation>
    <documentation xml:lang="en">The order of a SplineCalibrator refers to the interpolation function. Order 0 is a flat line from the defined point (inclusive) to the next point (exclusive). Order 1 is linear interpolation between two points. Order 2 is quadratic fit and requires at least 3 points (unusual case). This order is generally not needed, but may be used to override the interpolation order for this point.</documentation>
    </annotation>
    </attribute>
    <attribute name="raw" type="double" use="required">
    <annotation>
    <documentation xml:lang="en">The raw encoded value.</documentation>
    </annotation>
    </attribute>
    <attribute name="calibrated" type="double" use="required">
    <annotation>
    <documentation xml:lang="en">The engineering/calibrated value associated with the raw value for this point.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    ParameterType contents
    ================================================================================

    <complexType name="ParameterType">
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="ParameterProperties" type="xtce:ParameterPropertiesType" minOccurs="0"/>
    </sequence>
    <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="initialValue" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML
    schema (xs) type specified for each XTCE type:
    integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean;
    binary=xs:hexBinary; enum=xs:string from EnumerationList;
    relative time= xs:duration; absolute time=xs:dateTime;
    array/aggregate=comma separated list of values inside curly braces {}.
    Supplied value must be within the ValidRange specified for the type and
    is a calibrated value.
    </documentation>
    <appinfo>The value type must match the Parameter type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ParameterType">
    <annotation>
    <documentation xml:lang="en">Describe the properties of a telemetry parameter, including its data type (parameter type). The bulk of properties associated with a telemetry parameter are in its parameter type. The initial value specified here, overrides the initial value in the parameter type. A parameter may be local, in which case its parameter type would have no data encodings. Ideally such a definition would also set data source in parameter properties to ‘local’ but the syntax does not enforce this. See BaseDataType, BaseTimeDataType, and NameReferenceType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="ParameterProperties" type="xtce:ParameterPropertiesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Specify additional properties for this Parameter used by the implementation of tailor the behavior and attributes of the Parameter. When not specified, the defaults on the ParameterProperties element attributes are assumed.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Specify the reference to the parameter type from the ParameterTypeSet area using the path reference rules, either local to this SpaceSystem, relative, or absolute.</documentation>
    </annotation>
    </attribute>
    <attribute name="initialValue" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    <appinfo>The value type must match the Parameter type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    ArgumentType contents
    ================================================================================

    <complexType name="ArgumentType">
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="argumentTypeRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML
    schema (xs) type specified for each XTCE type:
    integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean;
    binary=xs:hexBinary; enum=xs:string from EnumerationList;
    relative time= xs:duration; absolute time=xs:dateTime;
    array/aggregate=comma separated list of values inside curly braces {}.
    Supplied value must be within the ValidRange specified for the type and
    is a calibrated value.
    </documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="ArgumentType">
    <annotation>
    <documentation xml:lang="en">An Argument has a name and can take on values with the underlying value type described by the ArgumentTypeRef. Describe the properties of a command argument referring to a data type (argument type). The bulk of properties associated with a command argument are in its argument type. The initial value specified here, overrides the initial value in the argument type. See BaseDataType, BaseTimeDataType and NameReferenceType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="argumentTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Specify the reference to the argument type from the ArgumentTypeSet area using the path reference rules, either local to this SpaceSystem, relative, or absolute.</documentation>
    </annotation>
    </attribute>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    <appinfo>The value type must match the Argument type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Yet more documentation updates from BitBucket subcommittee effort

  • Key: XTCE12-510
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Several issues have noted that the XTCE 1.0 and 1.1 annotations have been lacking. Many of the updates were performed in conjunction with other issues that were more topic oriented to a particular area. In this, many elements/attributes/types did not require attention and as a result, did not get an opportunity to get annotation updates. In addition, some areas that were touched were done prior to reconciling the annotation updates.

  • Reported: XTCE 1.1 — Tue, 30 Jan 2018 22:25 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose another set of annotation updates (part 3)

    This resolution includes the third set of annotation updates that covers most of the elements/attributes in the next few levels of depth in the XML. It is not proposed as a comprehensive and complete set, but appears to be ready for use/evaluation/voting.

    The list below is the typical method of showing the before and after of the XSD by type definition in the XSD. Each type is separated by a textual divider to make it easier to review.

    ================================================================================
    ArgumentAssignmentListType contents
    ================================================================================

    <complexType name="ArgumentAssignmentListType">
    <sequence>
    <element name="ArgumentAssignment" type="xtce:ArgumentAssignmentType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="ArgumentAssignmentListType">
    <annotation>
    <documentation xml:lang="en">Argument Assignments specialize a MetaCommand or BlockMetaCommand when inheriting from another MetaCommand. General argument values can be restricted to specific values to further specialize the MetaCommand. Use it to ‘narrow’ a MetaCommand from its base MetaCommand by specifying values of arguments for example, a power command may be narrowed to a power on’ command by assigning the value of an argument to ‘on’. See ArgumentAssignmentType and MetaCommandType.</documentation>
    </annotation>
    <sequence>
    <element name="ArgumentAssignment" type="xtce:ArgumentAssignmentType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Specialize this command definition when inheriting from a more general MetaCommand by restricting the specific values of otherwise general arguments.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    ArgumentAssignmentType contents
    ================================================================================

    <complexType name="ArgumentAssignmentType">
    <attribute name="argumentName" type="xtce:NameReferenceType" use="required"/>
    <attribute name="argumentValue" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML
    schema (xs) type specified for each XTCE type:
    integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean;
    binary=xs:hexBinary; enum=xs:string from EnumerationList;
    relative time= xs:duration; absolute time=xs:dateTime;
    array/aggregate=comma separated list of values inside curly braces {}.
    Supplied value must be within the ValidRange specified for the type and
    is a calibrated value.
    </documentation>
    </annotation>
    </attribute>
    </complexType>

    <complexType name="ArgumentAssignmentType">
    <annotation>
    <documentation xml:lang="en">Describe an assignment of an argument with a calibrated/engineering value. See ArgumentAssignmentListType.</documentation>
    </annotation>
    <attribute name="argumentName" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">The named argument from the base MetaCommand to assign/restrict with a value.</documentation>
    </annotation>
    </attribute>
    <attribute name="argumentValue" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time=xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the type.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    ArgumentListType contents (choice changed to sequence as it is more appropriate)
    ================================================================================

    <complexType name="ArgumentListType">
    <choice maxOccurs="unbounded">
    <element name="Argument" type="xtce:ArgumentType" maxOccurs="unbounded">
    <annotation>
    <appinfo>Need to ensure that the named types actually exist</appinfo>
    </annotation>
    </element>
    </choice>
    </complexType>

    <complexType name="ArgumentListType">
    <annotation>
    <documentation xml:lang="en">Defines a list of Arguments for a command definition.</documentation>
    </annotation>
    <sequence>
    <element name="Argument" type="xtce:ArgumentType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Defines an Argument for a command definition. Arguments are local to the MetaCommand, BlockMetaCommand, and those that inherit from the definition.</documentation>
    <appinfo>Need to ensure that the named types actually exist</appinfo>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    ArgumentFloatDataType contents
    ================================================================================

    Change limited to the initialValue attribute with copy/paste error in text from integer side. Existing is:

    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>

    Replace to:

    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
    </annotation>
    </attribute>

    ================================================================================
    IntegerRangeType contents
    ================================================================================

    <complexType name="IntegerRangeType">
    <annotation>
    <documentation xml:lang="en">An integral range of numbers. "min", and "max".</documentation>
    </annotation>
    <attribute name="minInclusive" type="long"/>
    <attribute name="maxInclusive" type="long"/>
    </complexType>

    <complexType name="IntegerRangeType">
    <annotation>
    <documentation xml:lang="en">Describe an integral based range: minInclusive and maxInclusive. Used in a number of locations related to ranges: ValidIntegerRangeSetType for example.</documentation>
    </annotation>
    <attribute name="minInclusive" type="long">
    <annotation>
    <documentation xml:lang="en">Minimum integer value including itself.</documentation>
    </annotation>
    </attribute>
    <attribute name="maxInclusive" type="long">
    <annotation>
    <documentation xml:lang="en">Maximum integer value including itself.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    FloatRangeType contents
    ================================================================================

    <complexType name="FloatRangeType">
    <annotation>
    <documentation xml:lang="en">A range of numbers. "minInclusive", "minExclusive", "maxInclusive" and "maxExclusive" attributes are borrowed from the W3C schema language.</documentation>
    </annotation>
    <attribute name="minInclusive" type="double"/>
    <attribute name="minExclusive" type="double"/>
    <attribute name="maxInclusive" type="double"/>
    <attribute name="maxExclusive" type="double"/>
    </complexType>

    <complexType name="FloatRangeType">
    <annotation>
    <documentation xml:lang="en">Describe a floating point based range, several types of ranges are supported – one sided and two sided, inclusive or exclusive. It would not make sense to set two mins or maxes. Used in a number of locations related to ranges: ValidFloatRangeSetType or AlarmRangeType for example.</documentation>
    <appinfo>Verify that the combination provided is usable.</appinfo>
    </annotation>
    <attribute name="minInclusive" type="double">
    <annotation>
    <documentation xml:lang="en">Minimum decimal/real number value including itself.</documentation>
    </annotation>
    </attribute>
    <attribute name="minExclusive" type="double">
    <annotation>
    <documentation xml:lang="en">Minimum decimal/real number value excluding itself.</documentation>
    </annotation>
    </attribute>
    <attribute name="maxInclusive" type="double">
    <annotation>
    <documentation xml:lang="en">Maximum decimal/real number value including itself.</documentation>
    </annotation>
    </attribute>
    <attribute name="maxExclusive" type="double">
    <annotation>
    <documentation xml:lang="en">Maximum decimal/real number value excluding itself.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    AlarmConditionsType contents
    ================================================================================

    <complexType name="AlarmConditionsType">
    <annotation>
    <documentation xml:lang="en">When the alarm is determined by boolean logic</documentation>
    </annotation>
    <sequence>
    <element name="WatchAlarm" type="xtce:MatchCriteriaType" minOccurs="0"/>
    <element name="WarningAlarm" type="xtce:MatchCriteriaType" minOccurs="0"/>
    <element name="DistressAlarm" type="xtce:MatchCriteriaType" minOccurs="0"/>
    <element name="CriticalAlarm" type="xtce:MatchCriteriaType" minOccurs="0"/>
    <element name="SevereAlarm" type="xtce:MatchCriteriaType" minOccurs="0"/>
    </sequence>
    </complexType>

    <complexType name="AlarmConditionsType">
    <annotation>
    <documentation xml:lang="en">Describe up to six levels: Normal, Watch, Warning, Distress, Critical, and Severe of conditions the alarm will trigger when true. The types are conditions available are a single comparison, a comparison list, a discrete lookup list, and custom algorithm. See MatchCriteriaType.</documentation>
    </annotation>
    <sequence>
    <element name="WatchAlarm" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An alarm state of least concern. Considered to be below the most commonly used Warning level.</documentation>
    </annotation>
    </element>
    <element name="WarningAlarm" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An alarm state of concern that represents the most commonly used minimum concern level for many software applications.</documentation>
    </annotation>
    </element>
    <element name="DistressAlarm" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An alarm state of concern in between the most commonly used Warning and Critical levels.</documentation>
    </annotation>
    </element>
    <element name="CriticalAlarm" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An alarm state of concern that represents the most commonly used maximum concern level for many software applications.</documentation>
    </annotation>
    </element>
    <element name="SevereAlarm" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">An alarm state of highest concern. Considered to be above the most commonly used Critical level.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    BinaryContextAlarmListType contents
    ================================================================================

    <complexType name="BinaryContextAlarmListType">
    <sequence>
    <element name="ContextAlarm" type="xtce:BinaryContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="BinaryContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context binary alarms, duplicates are valid. Process the contexts in list order. See BinaryContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:BinaryContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    ================================================================================
    ChangeValueType contents
    ================================================================================

    <complexType name="ChangeValueType">
    <attribute name="value" type="double" use="required"/>
    </complexType>

    <complexType name="ChangeValueType">
    <annotation>
    <documentation xml:lang="en">Describe a change value used to test verification status. See CommandVerifierType.</documentation>
    </annotation>
    <attribute name="value" type="double" use="required">
    <annotation>
    <documentation xml:lang="en">Value as a floating point number.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    CheckWindowAlgorithmsType contents
    ================================================================================

    <complexType name="CheckWindowAlgorithmsType">
    <annotation>
    <documentation xml:lang="en">Used when times must be calculated</documentation>
    </annotation>
    <sequence>
    <element name="StartCheck" type="xtce:InputAlgorithmType"/>
    <element name="StopTime" type="xtce:InputAlgorithmType"/>
    </sequence>
    </complexType>

    <complexType name="CheckWindowAlgorithmsType">
    <annotation>
    <documentation xml:lang="en">Used by CommandVerifiers to limit the time allocated to check for the verification. See CommandVerifierType.</documentation>
    </annotation>
    <sequence>
    <element name="StartCheck" type="xtce:InputAlgorithmType"/>
    <element name="StopTime" type="xtce:InputAlgorithmType"/>
    </sequence>
    </complexType>

    ================================================================================
    CheckWindowType contents
    ================================================================================

    <complexType name="CheckWindowType">
    <attribute name="timeToStartChecking" type="xtce:RelativeTimeType"/>
    <attribute name="timeToStopChecking" type="xtce:RelativeTimeType" use="required"/>
    <attribute name="timeWindowIsRelativeTo" type="xtce:TimeWindowIsRelativeToType" default="timeLastVerifierPassed"/>
    </complexType>

    <complexType name="CheckWindowType">
    <annotation>
    <documentation xml:lang="en">Used by CommandVerifiers to limit the time allocated to check for the verification. See CheckWindowAlgorithmsType.</documentation>
    </annotation>
    <attribute name="timeToStartChecking" type="xtce:RelativeTimeType"/>
    <attribute name="timeToStopChecking" type="xtce:RelativeTimeType" use="required"/>
    <attribute name="timeWindowIsRelativeTo" type="xtce:TimeWindowIsRelativeToType" default="timeLastVerifierPassed"/>
    </complexType>

    ================================================================================
    ContextCalibratorListType contents
    ================================================================================

    <complexType name="ContextCalibratorListType">
    <annotation>
    <documentation xml:lang="en">Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true</documentation>
    </annotation>
    <sequence>
    <element name="ContextCalibrator" type="xtce:ContextCalibratorType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="ContextCalibratorListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered list of calibrators with a context match. Useful when different calibrations must be used depending on a matching value. The first context that matches determines which calibrator to use. See IntegerDataEncodingType and FloatDataEncodingType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextCalibrator" type="xtce:ContextCalibratorType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a calibrator that depends on a matching value using a ContextMatch. When the context matches for the calibrator, the default calibrator is overridden, if it exists.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    ContextSignificanceType contents
    ================================================================================

    <complexType name="ContextSignificanceType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType"/>
    <element name="Significance" type="xtce:SignificanceType"/>
    </sequence>
    </complexType>

    <complexType name="ContextSignificanceType">
    <annotation>
    <documentation xml:lang="en">Describe a significance level for a MetaCommand definition where the significance level depends on matching a context value. See ContextMatchType and SignificanceType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType">
    <annotation>
    <documentation xml:lang="en">Describe the context matching value and source that will enable the Significance listed in the Significance element.</documentation>
    </annotation>
    </element>
    <element name="Significance" type="xtce:SignificanceType">
    <annotation>
    <documentation xml:lang="en">Describe the signficance of this MetaCommand definition. See SignificanceType.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    ContextSignificanceListType contents
    ================================================================================

    <complexType name="ContextSignificanceListType">
    <annotation>
    <documentation xml:lang="en">Used when the significance (possible consequence) of a command varies by the operating context</documentation>
    </annotation>
    <sequence>
    <element name="ContextSignificance" type="xtce:ContextSignificanceType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    <complexType name="ContextSignificanceListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered list of ContextSignificance elements where the significance on the first context match to test true is used as the significance of the MetaCommand. If there is a DefaultSignificance, it is overrideen by the matching context. See ContextSignificantType and MetaCommandType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextSignificance" type="xtce:ContextSignificanceType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a significance level for a MetaCommand definition where the significance level depends on matching a context value. See ContextMatchType and SignificanceType.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    DerivationType contents
    ================================================================================

    Discard definition:

    <complexType name="DerivationType">
    <annotation>
    <documentation>Result of the MathOperation will be the new Parameter value</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MathOperationType"/>
    </complexContent>
    </complexType>

    Repair definition from:

    <complexType name="ParameterToSetType">
    <annotation>
    <documentation xml:lang="en">Sets a Parameter to a new value (either from a derivation or explicitly) after the command has been verified (all verifications have passed)</documentation>
    <appinfo>Value type must match Parameter type</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterRefType">
    <choice>
    <element name="Derivation" type="xtce:DerivationType"/>
    <element name="NewValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML
    schema (xs) type specified for each XTCE type:
    integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean;
    binary=xs:hexBinary; enum=xs:string from EnumerationList;
    relative time= xs:duration; absolute time=xs:dateTime;
    array/aggregate=comma separated list of values inside curly braces {}.
    Supplied value must be within the ValidRange specified for the type and
    is a calibrated value.
    </documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="setOnVerification" type="xtce:VerifierEnumerationType" default="complete"/>
    </extension>
    </complexContent>
    </complexType>

    To:

    <complexType name="ParameterToSetType">
    <annotation>
    <documentation xml:lang="en">Sets a Parameter to a new value (either from a derivation or explicitly) after the command has been verified (all verifications have passed).</documentation>
    <appinfo>Value type must match Parameter type.</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterRefType">
    <choice>
    <element name="Derivation" type="xtce:MathOperationType">
    <annotation>
    <documentation xml:lang="en">Specify a MathOperation to use to set the Parameter value. See MathOperationType.</documentation>
    </annotation>
    </element>
    <element name="NewValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time= xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the Parameter and appropriate for the type.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="setOnVerification" type="xtce:VerifierEnumerationType" default="complete">
    <annotation>
    <documentation xml:lang="en">This attribute provides more specific control over when the Parameter value is set. By default, it is when the command have all verifications complete. See VerifierEnumerationType.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    DiscreteLookupListType contents
    ================================================================================

    <complexType name="DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Lookup a value using the lookup list supplied. Use the first match found.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:DiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    <complexType name="DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered table of integer values and associated conditions, forming a lookup table. The list may have duplicates. The table is evaluated from first to last, the first condition to be true returns the value associated with it. See DiscreteLookupType.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:DiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    ================================================================================
    EncodingType contents (only for absolute time)
    ================================================================================

    <complexType name="EncodingType">
    <annotation>
    <documentation xml:lang="en">Scale and offset are used in a y =mx +b type relationship (m is the scale and b is the offset) to make adjustments to the encoded value to that it matches the time units. Binary Encoded time is typically used with a user supplied transform algorithm to convert time data formats that are too difficult to describe in XTCE.</documentation>
    </annotation>
    <choice>
    <element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType"/>
    <element name="FloatDataEncoding" type="xtce:FloatDataEncodingType"/>
    <element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType"/>
    <element name="StringDataEncoding" type="xtce:StringDataEncodingType"/>
    </choice>
    <attribute name="units" type="xtce:TimeUnitsType" default="seconds"/>
    <attribute name="scale" type="double" default="1"/>
    <attribute name="offset" type="double" default="0"/>
    </complexType>

    Why do we have scale and offset when we have calibrators??? To revisit at a future RFP.

    <complexType name="EncodingType">
    <annotation>
    <documentation xml:lang="en">Describe the data encoding for a time data type. It includes the units and other attributes scale and offset. Use scale and offset to describe a y=mx+b relationship (where m is the slope/scale and b is the intercept/offset) to make adjustments to the encoded time value so that it matches the time units. For binary encoded time use transform algorithms to convert time data formats that are too difficult to describe in XTCE. See AbsoluteTimeDataType and RelativeTimeDataType.</documentation>
    </annotation>
    <choice>
    <element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Binary encoding is typically a "pass through" raw encoding form where one of the more common encodings is not required for the parameter. A custom transformation capability is available if needed.</documentation>
    </annotation>
    </element>
    <element name="FloatDataEncoding" type="xtce:FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Float encoding is a common encoding where the raw binary is in a form that gets interpreted as a decimal numeric value.</documentation>
    </annotation>
    </element>
    <element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Integer encoding is a common encoding where the raw binary is in a form that gets interpreted as an integral value, either signed or unsigned.</documentation>
    </annotation>
    </element>
    <element name="StringDataEncoding" type="xtce:StringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">String encoding is a common encoding where the raw binary is in a form that gets interpreted as a character sequence.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="units" type="xtce:TimeUnitsType" default="seconds">
    <annotation>
    <documentation xml:lang="en">Time units, with the default being in seconds.</documentation>
    </annotation>
    </attribute>
    <attribute name="scale" type="double" default="1">
    <annotation>
    <documentation xml:lang="en">Linear slope used as a shorter form of specifying a calibrator to convert between the raw value and the engineering units.</documentation>
    </annotation>
    </attribute>
    <attribute name="offset" type="double" default="0">
    <annotation>
    <documentation xml:lang="en">Linear intercept used as a shorter form of specifying a calibrator to convert between the raw value and the engineering units.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    FixedFrameSyncStrategyType contents
    ================================================================================

    <complexType name="FixedFrameSyncStrategyType">
    <complexContent>
    <extension base="xtce:SyncStrategyType">
    <sequence>
    <element name="SyncPattern" type="xtce:SyncPatternType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="FixedFrameSyncStrategyType">
    <annotation>
    <documentation xml:lang="en">Describe a sync pattern and an optional reference to an algorithm used to invert the stream if the frame sync pattern is not found. See FixedFrameStreamType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:SyncStrategyType">
    <sequence>
    <element name="SyncPattern" type="xtce:SyncPatternType">
    <annotation>
    <documentation xml:lang="en">The pattern of bits used to look for frame synchronization. See SyncPatternType.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    VariableFrameSyncStrategyType contents
    ================================================================================

    <complexType name="VariableFrameSyncStrategyType">
    <complexContent>
    <extension base="xtce:SyncStrategyType">
    <sequence>
    <element name="Flag" type="xtce:FlagType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="VariableFrameSyncStrategyType">
    <annotation>
    <documentation xml:lang="en">Describe the flag type (either all ones or all zeros), the flag length in bits and an optional reference to an algorithm used to invert the stream if the frame sync pattern is not found. See VariableFrameStreamType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:SyncStrategyType">
    <sequence>
    <element name="Flag" type="xtce:FlagType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    FLAG ELEMENT NEEDS SOMETHING - revisit at a later time.

    ================================================================================
    InterlockType contents
    ================================================================================

    <complexType name="InterlockType">
    <attribute name="scopeToSpaceSystem" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">The name of a SpaceSystem this Interlock applies to. By default, it only applies to the SpaceSystem that contains this MetaCommand.</documentation>
    </annotation>
    </attribute>
    <attribute name="verificationToWaitFor" type="xtce:VerifierEnumerationType" default="complete"/>
    <attribute name="verificationProgressPercentage" type="double">
    <annotation>
    <documentation xml:lang="en">Only applies when the verificationToWaitFor attribute is 'queued' or 'executing'.</documentation>
    </annotation>
    </attribute>
    <attribute name="suspendable" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">A flag that indicates that under special circumstances, this Interlock can be suspended.</documentation>
    </annotation>
    </attribute>
    </complexType>

    <complexType name="InterlockType">
    <annotation>
    <documentation xml:lang="en">Describe a type of constraint on the next command, rather than this command. Interlocks apply only to the next command. An interlock will block successive commands until this command has reached a certain stage of verifier. Interlocks are scoped to a SpaceSystem basis: they by default apply to the SpaceSystem the MetaCommand is defined in but this may be overridden. See MetaCommandType and VerifierSetType.</documentation>
    </annotation>
    <attribute name="scopeToSpaceSystem" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">The name of a SpaceSystem this Interlock applies to. By default, it only applies to the SpaceSystem that contains this MetaCommand.</documentation>
    </annotation>
    </attribute>
    <attribute name="verificationToWaitFor" type="xtce:VerifierEnumerationType" default="complete">
    <annotation>
    <documentation xml:lang="en">The verification stage of the command that releases the interlock, with the default being complete.</documentation>
    </annotation>
    </attribute>
    <attribute name="verificationProgressPercentage" type="double">
    <annotation>
    <documentation xml:lang="en">Only applies when the verificationToWaitFor attribute is 'queued' or 'executing'.</documentation>
    </annotation>
    </attribute>
    <attribute name="suspendable" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">A flag that indicates that under special circumstances, this Interlock can be suspended.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    MathAlgorithmType contents
    ================================================================================

    <complexType name="MathAlgorithmType">
    <annotation>
    <documentation xml:lang="en">A simple mathematical operation</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="MathOperation" type="xtce:TriggeredMathOperationType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="MathAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Describe a postfix (Reverse Polish Notation (RPN)) notation based mathmatical equations. See MathOperationType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="MathOperation" type="xtce:TriggeredMathOperationType">
    <annotation>
    <documentation xml:lang="en">The contents of the Math Operation as an algorithm definition in RPN. See TriggeredMathOperationType.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    PhysicalAddressType contents
    ================================================================================

    <complexType name="PhysicalAddressType" mixed="false">
    <annotation>
    <documentation xml:lang="en">When it's important to know the physical address(s) on the spacecraft that this parameter may be collected from, use this. </documentation>
    </annotation>
    <sequence>
    <element name="SubAddress" type="xtce:PhysicalAddressType" minOccurs="0"/>
    </sequence>
    <attribute name="sourceName" type="string"/>
    <attribute name="sourceAddress" type="string"/>
    </complexType>

    <complexType name="PhysicalAddressType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Describe the physical address(s) that this parameter is collected from. Examples of physical addresses include a memory location on the spacecraft or a location on a data collection bus, with the source identified with a descriptive name for the region of memory, such as RAM, Flash, EEPROM, and other possibilities that can be adapted for program specific usage.</documentation>
    </annotation>
    <sequence>
    <element name="SubAddress" type="xtce:PhysicalAddressType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A sub-address may be used to further specify the location if it fractionally occupies the address. Additional possibilities exist for separating partitions of memory or other address based storage mechanisms. This specification does not specify spacecraft specific hardware properties, so usage of addressing information is largely program and platform specific.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="sourceName" type="string">
    <annotation>
    <documentation xml:lang="en">A descriptive name for the location, such as a memory type, where this address is located.</documentation>
    </annotation>
    </attribute>
    <attribute name="sourceAddress" type="string">
    <annotation>
    <documentation xml:lang="en">The address within the memory location. This specification does not specify program and hardware specific attributes, such as address size and address region starting location. These are part of the spacecraft hardware properties.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    RateInStreamType contents
    ================================================================================

    <complexType name="RateInStreamType">
    <annotation>
    <documentation xml:lang="en">Used in packaging to define the expected rate that any individual container will be in a Stream</documentation>
    </annotation>
    <attribute name="basis" type="xtce:BasisType" default="perSecond"/>
    <attribute name="minimumValue" type="double"/>
    <attribute name="maximumValue" type="double"/>
    </complexType>

    <complexType name="RateInStreamType">
    <annotation>
    <documentation xml:lang="en">Define the expected appearance (rate) of a container in a stream where the rate is defined on either a perSecond or perContainer update basis. Many programs and platforms have variable reporting rates for containers and these can be commanded. As a result, this element is only useful to some users and generally does not affect the processing of the received containers themselves. See ContainerType.</documentation>
    </annotation>
    <attribute name="basis" type="xtce:BasisType" default="perSecond">
    <annotation>
    <documentation xml:lang="en">The measurement unit basis for the minimum and maximum appearance count values.</documentation>
    </annotation>
    </attribute>
    <attribute name="minimumValue" type="double">
    <annotation>
    <documentation xml:lang="en">The minimum rate for the specified basis for which this container should appear in the stream.</documentation>
    </annotation>
    </attribute>
    <attribute name="maximumValue" type="double">
    <annotation>
    <documentation xml:lang="en">The maximum rate for the specified basis for which this container should appear in the stream.</documentation>
    </annotation>
    </attribute>
    </complexType>

    ================================================================================
    RateInStreamWithStreamNameType contents
    ================================================================================

    <complexType name="RateInStreamWithStreamNameType">
    <complexContent>
    <extension base="xtce:RateInStreamType">
    <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="RateInStreamWithStreamNameType">
    <annotation>
    <documentation xml:lang="en">Define the expected appearance (rate) of a container in a named stream where the rate is defined on either a perSecond or perContainer update basis. Many programs and platforms have variable reporting rates for containers and these can be commanded. As a result, this element is only useful to some users and generally does not affect the processing of the received containers themselves. See ContainerType and RateInStreamType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:RateInStreamType">
    <attribute name="streamRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Reference to a named stream for which this rate specification applies.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    RestrictionCriteriaType contents
    ================================================================================

    <complexType name="RestrictionCriteriaType">
    <annotation>
    <documentation xml:lang="en">Given that this Container is the Base container type, RestrictionCriteria lists conditions that must be true for this Container to be 'this' subContainer type. May be a simple Comparison List, a Boolean Expression, and/or in a Graph of containers established by the NextContainer</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType">
    <choice>
    <element name="NextContainer" type="xtce:ContainerRefType" minOccurs="0"/>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    <complexType name="RestrictionCriteriaType">
    <annotation>
    <documentation xml:lang="en">Define one or more conditions (constraints) for container inheritance. A container is instantiable if its constraints are true. Constraint conditions may be a comparison, a list of comparisons, a boolean expression, or a graph of containers that are instantiable (if all containers are instantiable the condition is true). See BaseContainerType, ComparisonType, ComparisonListType, BooleanExpressionType and NextContainerType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType">
    <choice>
    <element name="NextContainer" type="xtce:ContainerRefType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Reference to the named container that must follow this container in the stream sequence.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    ================================================================================
    BasisType contents
    ================================================================================

    <simpleType name="BasisType">
    <restriction base="string">
    <enumeration value="perSecond"/>
    <enumeration value="perContainerUpdate"/>
    </restriction>
    </simpleType>

    <simpleType name="BasisType">
    <annotation>
    <documentation xml:lang="en">Defines to type of update rates: perSecond and perContainerUpdate. See RateInStreamType.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="perSecond"/>
    <enumeration value="perContainerUpdate"/>
    </restriction>
    </simpleType>

    ================================================================================
    ChangeBasisType contents
    ================================================================================

    <simpleType name="ChangeBasisType">
    <restriction base="string">
    <enumeration value="absoluteChange"/>
    <enumeration value="percentageChange"/>
    </restriction>
    </simpleType>

    <simpleType name="ChangeBasisType">
    <annotation>
    <documentation xml:lang="en">Defines absoluteChange and percentageChange for use in rate of change alarms. Used by ChangeAlarmRangesType.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="absoluteChange"/>
    <enumeration value="percentageChange"/>
    </restriction>
    </simpleType>

    ================================================================================
    ChangeSpanType contents
    ================================================================================

    <simpleType name="ChangeSpanType">
    <restriction base="string">
    <enumeration value="changePerSecond"/>
    <enumeration value="changePerSample"/>
    </restriction>
    </simpleType>

    <simpleType name="ChangeSpanType">
    <annotation>
    <documentation xml:lang="en">Defines a changePerSecond and changePerSample for use in rate of change alarms. Used by ChangeAlarmRangesType.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="changePerSecond"/>
    <enumeration value="changePerSample"/>
    </restriction>
    </simpleType>

    ================================================================================
    BitOrderType contents
    ================================================================================

    <simpleType name="BitOrderType">
    <restriction base="string">
    <enumeration value="leastSignificantBitFirst"/>
    <enumeration value="mostSignificantBitFirst"/>
    </restriction>
    </simpleType>

    <simpleType name="BitOrderType">
    <annotation>
    <documentation xml:lang="en">Defines two bit-order types: most significant bit first and least significant bit first. See DataEncodingType.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="leastSignificantBitFirst"/>
    <enumeration value="mostSignificantBitFirst"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Combination Alarm

  • Key: XTCE12-53
  • Legacy Issue Number: 19374
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A combination alarm allows conditions to be checked on multiple telemetry channels, and the resulting alarm conditions set on multiple telemetry channels. The source channels (which trigger the alarm) and the target channels (which show the alarm) do not have to be the same. One alarm level applies to all of the source alarms included in the combination set. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Combination alarm capability reasonably exists in existing improvements

    The original submitter for this issue has suggested two things:

    (1) They have redesigned their original system to change the need that resulted in this issue.

    (2) The latest improvements incorporated with other issues have made it possible to address their latest needs without a separate change here.

    For these reasons, we are proposing to close this without change.

  • Updated: Tue, 10 Jul 2018 14:23 GMT

TimeAssociation should be settable at the Container

  • Key: XTCE12-1
  • Legacy Issue Number: 14464
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to include the TimeAssociation proposal at SequenceEntry type

    The working group created a proposal to include updates to the SequenceEntryType to incorporate TimeAssociation element options.

    The existing TimeAssociationType gets some minor updates to the documentation. Replace the existing schema type:

    <complexType name="TimeAssociationType">
    <annotation>
    <documentation xml:lang="en">Telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. </documentation>
    <appinfo>The parameter ref must be to an AbsoluteTime Parameter</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterInstanceRefType">
    <attribute name="interpolateTime" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">If true, then the current value of the AbsoluteTime will be projected to current time. In other words, if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to its value before associating this time with the parameter.</documentation>
    </annotation>
    </attribute>
    <attribute name="offset" type="double">
    <annotation>
    <documentation xml:lang="en">The offset is used to supply a relative time offset from the time association and to this parameter</documentation>
    </annotation>
    </attribute>
    <attribute name="unit" type="xtce:TimeAssociationUnitType" default="si_second">
    <annotation>
    <documentation>Specify the units the offset is in, the default is si_second.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    With the following new content for this schema type:

    <complexType name="TimeAssociationType">
    <annotation>
    <documentation xml:lang="en">Describes a time association consisting of an instance of an absolute time parameter (parameterRef) and this entry. Because telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. See AbsoluteTimeParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterInstanceRefType">
    <attribute name="interpolateTime" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">If true, then the current value of the AbsoluteTime will be projected to current time. In other words, if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to its value before associating this time with the parameter.</documentation>
    </annotation>
    </attribute>
    <attribute name="offset" type="double">
    <annotation>
    <documentation xml:lang="en">The offset is used to supply a relative time offset from the time association and to this parameter</documentation>
    </annotation>
    </attribute>
    <attribute name="unit" type="xtce:TimeAssociationUnitType" default="si_second">
    <annotation>
    <documentation xml:lang="en">Specify the units the offset is in, the default is si_second.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Then update the existing SequenceEntryType content from:

    <complexType name="SequenceEntryType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An abstract type used by sequence containers. An entry contains a location in the container. The location may be either fixed or dynamic, absolute (to the start or end of the enclosing container, or relative (to either the previous or subsequent entry). Entries may also repeat.</documentation>
    </annotation>
    <sequence>
    <element name="LocationInContainerInBits" type="xtce:LocationInContainerInBitsType" minOccurs="0"/>
    <element name="RepeatEntry" type="xtce:RepeatType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">
    May be used when this entry repeats itself in
    the sequence container. If not supplied, the
    entry does not repeat.
    </documentation>
    </annotation>
    </element>
    <element name="IncludeCondition" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">
    This entry will only be included in the sequence
    when this condition is true. If no
    IncludeCondition is given, then it is will be
    included. A parameter that is not included will
    be treated as if it did not exist in the
    sequence at all.
    </documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="shortDescription" type="string" use="optional"/>
    </complexType>

    To the new definition that also incorporates annotation improvements to enhance clarity of the usage:

    <complexType name="SequenceEntryType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Defines an abstract schema type used to create other entry types. Describe an entry’s location in the container (See LocationInContainerInBitsType). The location may be fixed or dynamic, absolute or relative. Entries may be included depending on the value of a condition (See IncludeConditionType), and entries may also repeat (see RepeatEntryType). The entry’s IncludeCondition resolves to true, it is fully-resolved when its size is computable after RepeatEntry has been accounted for and then offset by LocationInContainer. See EntryListType, IncludeConditionType, RepeatEntryType and LocationInContainerInBitsType.</documentation>
    </annotation>
    <sequence>
    <element name="LocationInContainerInBits" type="xtce:LocationInContainerInBitsType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The start bit 0 position for each container is local to the container, but does include space occupied by inherited containers. When a container is "included", as opposed to inherited, then the interpreting implementation takes into account the start bit position of the referring container when finally assembling the start bits for the post-processed entry content. The default start bit for any entry is 0 bits from the previous entry, making the content contiguous when this element is not used.</documentation>
    </annotation>
    </element>
    <element name="RepeatEntry" type="xtce:RepeatType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">May be used when this entry repeats itself in the sequence container. When an entry repeats, it effectively specifies that the same entry is reported more than once in the container and has the same physical meaning. This should not be construed to be equivalent to arrays.</documentation>
    </annotation>
    </element>
    <element name="IncludeCondition" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This entry will only be included in the sequence when this condition is true, otherwise it is always included. When the include condition evaluates to false, it is as if the entry does not exist such that any start bit interpretations cannot take into account the space that would have been occupied if this included condition were true.</documentation>
    </annotation>
    </element>
    <element name="TimeAssociation" type="xtce:TimeAssociationType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional timing information associated with this entry.</documentation>
    </annotation>
    </element>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional ancillary data associated with this element.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional short description for this entry element.</documentation>
    </annotation>
    </attribute>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Align ArgumentType and ParameterType construction

  • Key: XTCE12-114
  • Legacy Issue Number: 14476
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-92

    Several issue resolutions deal with refactoring Argument type definitions. The specific topic of this issue is already covered. The types now have a common base type.

  • Updated: Tue, 10 Jul 2018 14:23 GMT

Derive ArgumentTypes by extension

  • Key: XTCE12-92
  • Legacy Issue Number: 14498
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-114

    This issue is substantively the same as XTCE12-114 and that one better describes the approach decided upon.

  • Updated: Tue, 10 Jul 2018 14:23 GMT

AlarmType produces problem in JaxB

  • Key: XTCE12-119
  • Legacy Issue Number: 14465
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Issue with AlarmType features already resolved

    The requested items in issue XTCE12-119 have been incorporated in previous resolutions.

  • Updated: Tue, 10 Jul 2018 14:23 GMT

AbsoluteTimeParameterType Epoch is not always at midnight

  • Key: XTCE12-448
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The Epoch element in the time types does not allow an XTCE user to specify an Epoch date that is not anchored at midnight. At present it is a union of xs:date and xs:string with a restriction on 1 value, which is TAI.

  • Reported: XTCE 1.1 — Thu, 25 May 2017 13:23 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to update the Epoch element in time types

    Additional backwards compatible updates to the Epoch element will resolve this issue.

    First, update the annotations in the complexType ReferenceTimeType. Replace the existing type element in the schema with this content:

    <complexType name="ReferenceTimeType">
    <annotation>
    <documentation xml:lang="en">Most time values are relative to another time e.g. seconds are relative to minutes, minutes are relative to hours. This type is used to describe this relationship starting with the least significant time Parameter to and progressing to the most significant time parameter. </documentation>
    </annotation>
    <choice>
    <element name="OffsetFrom" type="xtce:ParameterInstanceRefType"/>
    <element name="Epoch" type="xtce:EpochType">
    <annotation>
    <documentation xml:lang="en">Epochs may be specified as an xs date where time is implied to be 00:00:00, xs dateTime, or string enumeration of common epochs. The enumerations are TAI (used by CCSDS and others), J2000, UNIX (also known as POSIX), and GPS.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Next, update the simpleType named EpochType with updated annotation and additional options in the union. In addition, the previous type named "TAIType" is renamed to be more accurate following this change. It is now named "EpochTimeEnumsType":

    <simpleType name="EpochType">
    <annotation>
    <documentation xml:lang="en">Epochs may be specified as an xs date where time is implied to be 00:00:00, xs dateTime, or string enumeration of common epochs. The enumerations are TAI (used by CCSDS and others), J2000, UNIX (also known as POSIX), and GPS.</documentation>
    </annotation>
    <union memberTypes="date dateTime xtce:EpochTimeEnumsType"/>
    </simpleType>

    Now replace the existing type "TAIType" with the "EpochTimeEnumsType" as shown below:

    <simpleType name="EpochTimeEnumsType">
    <annotation>
    <documentation xml:lang="en">Union values of common epoch definitions for document convenience.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="TAI"/>
    <enumeration value="J2000"/>
    <enumeration value="UNIX"/>
    <enumeration value="GPS"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

LongDescriptionType as a complexType is unnecessary

  • Key: XTCE12-454
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    In the schema refactoring for 1.2, the LongDescription element content got converted to a complexType containing just a string. This should be a simpleType.

  • Reported: XTCE 1.1 — Thu, 1 Jun 2017 17:51 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Convert complexType for LongDescriptionType to a simpleType

    Propose to simplify LongDescriptionType since it does not add any attributes to the description string that would justify a more complex generated interface. Maintaining it as a separate simpleType is useful for creating a profile that limits the length or otherwise restricts the string content, but the string can be retrieved from JAXB-generated code with the method getLongDescription() of the DescriptionType class.

    Change the complexType LongDescriptionType to a simpleType based on string as shown below:

    <simpleType name="LongDescriptionType">
    <annotation>
    <documentation xml:lang="en">The Long Description is intended to be used for explanatory descriptions of the object and may include HTML markup. Long Descriptions are of unbounded length</documentation>
    </annotation>
    <restriction base="string"/>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Derived Issue: Update integer alarm definition types

  • Key: XTCE12-490
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    This new issue is derived from existing issues because it is not possible to attach more than 1 resolution to an issue.

  • Reported: XTCE 1.1 — Sun, 29 Oct 2017 14:26 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update alarm type for integer alarm definitions

    This is the fourth resolution for the alarm definition issue. The overall resolution is broken up into several smaller resolutions for ease of review.

    Some aspects of the IntegerParameterType complexType have already been updated in previous issue resolutions. This update is based on the XSD as it exists post-ballot 13. As a result, some of the intended changes were already implemented.

    Also, some of the XSD types used in the Integer parameters are also used by the Float parameters. As a result, that parameter type will also be updated to the extent appropriate.

    The creation of the new NumericContextAlarmListType occurred in a previous resolution. For this resolution, first the IntegerParameterType has updated documentation.

    The current state of the proposal shows the complexType IntegerParameterType as such:

    <complexType name="IntegerParameterType">
    <complexContent>
    <extension base="xtce:IntegerDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0"/>
    <element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Add documentation elements to the schema changing the form of the definition to:

    <complexType name="IntegerParameterType">
    <annotation>
    <documentation xml:lang="en">Describe an integer parameter type. Several are supported. Calibrated integer to integer relationships should be described with this data type. Use the integer data encoding to define calibrators. Joins float as one of the numerics. See IntegerDataEncoding and IntegerDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:IntegerDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Next update the documentation content for the complexType NumericContextAlarmListType. The current proposed content of this type is:

    <complexType name="NumericContextAlarmListType">
    <sequence>
    <element name="ContextAlarm" type="xtce:NumericContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    Add documentation such that the definition appears as:

    <complexType name="NumericContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">An ordered collection of numeric alarms associated with a context. A context is an alarm definition on a parameter which is valid only in the case of a test on the value of other parameters. Process the contexts in list order. Used by both FloatParameterType and IntegerParameterType. See NumericContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:NumericContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A contextual alarm definition for the parameter that uses this type that is valid when a test against the value of one or more other parameters evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Next update the documentation content for the complexType NumericContextAlarmType. The current proposed content of this type is:

    <complexType name="NumericContextAlarmType">
    <annotation>
    <documentation xml:lang="en">Context alarms are applied when the ContextMatch is true. Context alarms override Default alarms</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NumericAlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Add documentation such that the definition appears as:

    <complexType name="NumericContextAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter dependent context, that when evaluates to true, enables the use of this alarm definition. See ContextMatchType and NumericAlarmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NumericAlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType">
    <annotation>
    <documentation xml:lang="en">Contains the evaluation criteria for a parameter dependent test, that when evaluates to true, enables this alarm definition.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    The previous definition of the complexType AlarmRangesType gets updated documentation. The current proposed definition of AlarmRangesType is:

    <complexType name="AlarmRangesType">
    <annotation>
    <documentation xml:lang="en">Contains five ranges: Watch, Warning, Distress, Critical, and Severe each in increasing severity. Normally, only the Warning and Critical ranges are used and the color yellow is associated with Warning and the color red is associated with Critical. The ranges given are valid for numbers lower than the min and higher than the max values. These ranges should not overlap, but if they do, assume the most severe range is to be applied. All ranges are optional and it is quite allowed for there to be only one end of the range. Range values are in calibrated engineering units.</documentation>
    </annotation>
    <sequence>
    <element name="WatchRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="WarningRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="DistressRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="CriticalRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="SevereRange" type="xtce:FloatRangeType" minOccurs="0"/>
    </sequence>
    </complexType>

    Replace the definition above with a new complexType that has additional annotation:

    <complexType name="AlarmRangesType">
    <annotation>
    <documentation xml:lang="en">Describe up to six ranges where either less severe ranges are a subset of more severe ranges (outside), or more severe ranges are a subset of less severe ranges (inside). In both forms, the undefined least severe range is normal. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <element name="WatchRange" type="xtce:FloatRangeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A range of least concern. Considered to be below the most commonly used Warning level.</documentation>
    </annotation>
    </element>
    <element name="WarningRange" type="xtce:FloatRangeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A range of concern that represents the most commonly used minimum concern level for many software applications.</documentation>
    </annotation>
    </element>
    <element name="DistressRange" type="xtce:FloatRangeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A range of concern in between the most commonly used Warning and Critical levels.</documentation>
    </annotation>
    </element>
    <element name="CriticalRange" type="xtce:FloatRangeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A range of concern that represents the most commonly used maximum concern level for many software applications.</documentation>
    </annotation>
    </element>
    <element name="SevereRange" type="xtce:FloatRangeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A range of highest concern. Considered to be above the most commonly used Critical level.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation xml:lang="en">A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch. The most common form used is "outside" and is the default.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next, in the complexType ChangeAlarmRangesType, there is a documentation update and also two attribute schema type updates. The current proposed definition for the ChangeAlarmRangesType is:

    <complexType name="ChangeAlarmRangesType">
    <annotation>
    <documentation xml:lang="en">ChangeAlarmRanges are used to trigger alarms when the parameter value's rate-of-change is either too fast or too slow. The change may be with respect to time (the default) or with respect to samples (delta alarms) - the changeType attribute determines this. The change may also be ether relative (as a percentage change) or absolute as set by the changeBasis attribute. The alarm also requires the spanOfInterest in both samples and seconds to have passed before it is to trigger. For time based rate of change alarms, the time specified in spanOfInterestInSeconds is used to calculate the change. For sample based rate of change alarms, the change is calulated over the number of samples specified in spanOfInterestInSeconds.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmRangesType">
    <attribute name="changeType" type="xtce:ChangeSpanType" default="changePerSecond"/>
    <attribute name="changeBasis" type="xtce:ChangeBasisType" default="absoluteChange"/>
    <attribute name="spanOfInterestInSamples" type="positiveInteger" default="1"/>
    <attribute name="spanOfInterestInSeconds" type="decimal" default="0"/>
    </extension>
    </complexContent>
    </complexType>

    The updated definition is:

    <complexType name="ChangeAlarmRangesType">
    <annotation>
    <documentation xml:lang="en">Describe an alarm when the parameter value's rate-of-change is either too fast or too slow. The change may be with respect to time (the default) or with respect to samples (delta alarms). Use the changeType attribute to select the type: changePerSecond (time) or changePerSample (delta). The change may also be ether relative (as a percentage change) or absolute as set by the changeBasis attribute. (Delta alarms are typically absolute but percentage is conceivable). The alarm also requires the spanOfInterest in both samples and seconds to have passed before it is to trigger. For time based rate of change alarms, the time specified in spanOfInterestInSeconds is used to calculate the change. For sample based rate of change alarms, the change is calculated over the number of samples specified in spanOfInterestInSamples. A typical delta alarm would set: changeType=changePerSample, changeBasis=absoluteChange, spanOfInterestInSamples=1. A typical time based version would set: changeType=changePerSecond, changeBasis=percentageChange, and spaceOfInterestInSeconds=1. To set the ranges use maxInclusive, the following definition applies: | Normal.maxInclusive | &lt;= | Watch.maxInclusive | &lt;= | Warning.maxInclusive | &lt;= | Distress.maxInclusive | &lt;= | Critical.maxInclusive | &lt;= | Severe.maxInclusive |. And it is further assumed the absolute value of each range and sampled value it taken to evaluate the alarm. See NumericAlarmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmRangesType">
    <attribute name="changeType" type="xtce:ChangeSpanType" default="changePerSecond"/>
    <attribute name="changeBasis" type="xtce:ChangeBasisType" default="absoluteChange"/>
    <attribute name="spanOfInterestInSamples" type="xtce:PositiveLongType" default="1"/>
    <attribute name="spanOfInterestInSeconds" type="double" default="0"/>
    </extension>
    </complexContent>
    </complexType>

    The last step for this resolution is to update the documentation for the complexType NumericAlarmType. The current state of this definition in the proposed XSD is:

    <complexType name="NumericAlarmType">
    <annotation>
    <documentation xml:lang="en">Alarms associated with numeric data types</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="StaticAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value</documentation>
    </annotation>
    </element>
    <element name="ChangeAlarmRanges" type="xtce:ChangeAlarmRangesType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Update the definition to the following to enhance the documentation:

    <complexType name="NumericAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe alarm conditions specific to the numeric data types, extends the basic AlarmType with StaticAlarmRanges and ChangeAlarmRanges. See FloatParameterType and IntegerParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="StaticAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value.</documentation>
    </annotation>
    </element>
    <element name="ChangeAlarmRanges" type="xtce:ChangeAlarmRangesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">ChangeAlarmRanges are used to trigger alarms when the parameter value changes by a rate or quantity from a reference.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Derived Issue: Update enumerated alarm definition types

  • Key: XTCE12-489
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    This new issue is derived from existing issues because it is not possible to attach more than 1 resolution to an issue.

  • Reported: XTCE 1.1 — Sun, 29 Oct 2017 14:26 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update alarm type for enumerated alarm definitions

    This is the third resolution for the alarm definition issue. The overall resolution is broken up into several smaller resolutions for ease of review.

    Some aspects of the EnumeratedParameterType complexType have already been updated in previous issue resolutions. This update is based on the XSD as it exists post-ballot 13. As a result, some of the intended changes were already implemented.

    The first step is to update the complexType for EnumerationAlarmLevelType. This gets a documentation element update and a rename of the "enumerationValue" attribute to "enumerationLabel" to be more clear to the user.

    <complexType name="EnumerationAlarmLevelType">
    <annotation>
    <documentation xml:lang="en">Describe an alarm level and its enumeration label to trigger from. See EnumeratedAlarmType and EnumeratedParameterType.</documentation>
    </annotation>
    <attribute name="alarmLevel" type="xtce:ConcernLevelsType" use="required">
    <annotation>
    <documentation xml:lang="en">Defines six levels: Normal, Watch, Warning, Distress, Critical and Severe. Typical implementations color the "normal" level as green, "warning" level as yellow, and "critical" level as red. In the case of enumeration alarms, the "normal" is assumed by implementations to be any label not otherwise in an alarm state.</documentation>
    </annotation>
    </attribute>
    <attribute name="enumerationLabel" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">The enumeration label is the engineering/calibrated value for enumerated types.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Next, update the documentation element in the "EnumerationContextAlarmType" complexType to be more descriptive.

    <complexType name="EnumerationContextAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe a context that when true the alarm condition may be evaluated. See ContextMatchType and EnumerationAlarmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:EnumerationAlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType">
    <annotation>
    <documentation xml:lang="en">Describe a context in terms of a parameter and value that when true enables the context alarm definition.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Next, update the documentation element in the "EnumerationAlarmListType" complexType to be more descriptive.

    <complexType name="EnumerationAlarmListType">
    <sequence>
    <element name="EnumerationAlarm" type="xtce:EnumerationAlarmLevelType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe an alarm state for an enumeration label where the label is engineer/calibrated value. Note that labels may represent multiple raw/uncalbrated values.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    The "EnumerationAlarmType" complexType also gets an update to the documentation annotation. It is significantly expanded from the original text.

    <complexType name="EnumerationAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe alarm conditions specific to the enumeration data type, extends the basic AlarmType with an EnumerationAlarmList. The alarms are described using the label (engineering/calibrated value) of the enumerated parameter. Enumeration labels may represent several raw/uncalibrated values, so as a result, a single alarm definition here may represent multiple raw values in the enumerated parameter. It is not necessary to define an alarm for raw/uncalibrated values that do not map to an enumeration. Implementations should implicitly define this as an alarm case, of which the manifestation of that is program/implementation specific. See EnumeratedParameterType.</documentation>
    <appinfo>An additional check needs to be performed to ensure that the enumeration values in the alarms are valid enumeration values for the Parameter</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="EnumerationAlarmList" type="xtce:EnumerationAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">List of alarm state definitions for this enumerated type.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="defaultAlarmLevel" type="xtce:ConcernLevelsType" default="normal">
    <annotation>
    <documentation xml:lang="en">Alarm state name for when no enumeration alarms evaluate to true. This defaults to "normal", which is almost always the case. Setting it to another alarm state permits a form of "inverted logic" where the alarm list can specify the normal states instead of the alarm states.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Also a relatively minor change to the "EnumerationContextAlarmListType" complexType annotation documentation to expand upon the descriptions.

    <complexType name="EnumerationContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context enumeration alarms, duplicates are valid. Process the contexts in list order. See EnumerationContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:EnumerationContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe the alarm matching context criteria and the alarm definition itself.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Lastly, update the complexType EnumeratedParameterType to introduce annotation to the alarm definition elements. Replace the existing EnumeratedParameterType with the revised definition below:

    <complexType name="EnumeratedParameterType">
    <complexContent>
    <extension base="xtce:EnumeratedDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:EnumerationAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state. The default definition applies when there are no context alarm definitions or all the context alarm definitions evaluate to false in their matching criteria.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:EnumerationContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state when another parameter and value combination evaluates to true using the described matching criteria.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Derived Issue: Update string alarm definition types

  • Key: XTCE12-488
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    This new issue is derived from existing issues because it is not possible to attach more than 1 resolution to an issue.

  • Reported: XTCE 1.1 — Sun, 29 Oct 2017 14:25 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update alarm type for string alarm definitions

    This is the second resolution for the alarm definition issues. The overall resolution is broken up into several smaller resolutions for ease of review.

    In the complexType "StringAlarmLevelType", first replace the documentation element in the annotations with the following update.

    <documentation xml:lang="en">Describe a string alarm condition based on matching a regular expression. The level and regular expression are described. The specific implementation of the regular expression syntax is not specified in the schema at this time. See StringAlarmListType.</documentation>

    Next, in the complexType "StringAlarmListType", add a new annotation element and documentation where it did not exist previously. The type definition with the annotation/documentation elements added is below.

    <complexType name="StringAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of string alarms, where duplicates are valid. Evaluate the alarms in list order. The first to evaluate to true takes precedence. See StringAlarmLevelType.</documentation>
    </annotation>
    <sequence>
    <element name="StringAlarm" type="xtce:StringAlarmLevelType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    Next, replace the existing definition complexType for "StringAlarmType" with the following definition.

    <complexType name="StringAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe alarms specific to the string data type, extends the basic AlarmType, while adding a StringAlarmList and defaultAlarmLevel attribute. The string alarm list is evaluated in list order. See ConcernsLevelsType and StringAlarmListType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="StringAlarmList" type="xtce:StringAlarmListType" minOccurs="0"/>
    </sequence>
    <attribute name="defaultAlarmLevel" type="xtce:ConcernLevelsType" default="normal"/>
    </extension>
    </complexContent>
    </complexType>

    In the complexType "StringContextAlarmType", add a new annotation/documentation element as shown in the complexType below. The type already exists, just the annotation is needed.

    <complexType name="StringContextAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe a context that when true the alarm may be evaluated. See ContextMatchType and StringAlarmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:StringAlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    In similar fashion to the above, add a new annotation/documentation element to the complexType "StringContextAlarmListType" as described below. The type already exists, but the annotation does not.

    <complexType name="StringContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">An ordered collection of numeric alarms associated with a context. Process the contexts in list order. See StringContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:StringContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Derived Issue: Update base alarm definition types

  • Key: XTCE12-487
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    This new issue is derived from existing issues because it is not possible to attach more than 1 resolution to an issue.

  • Reported: XTCE 1.1 — Sun, 29 Oct 2017 14:25 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update alarm type base definition types

    This is the first resolution for the alarm definition issues. The overall resolution is broken up into several smaller resolutions for ease of review. A number of alarm changes have already been applied in other resolutions.

    The first change is to update the complexType named "BaseAlarmType" immediately after the "AlarmType" definition. This will be used in the next update. This change applies annotation updates and sets the @name to be optional.

    <complexType name="BaseAlarmType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Supplies an optional non-reference-able name and short description for alarms. Also includes an optional ancillary data for any special local flags, note that these may not necessarily transfer to another recipient of an instance document.</documentation>
    </annotation>
    <sequence>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0"/>
    </sequence>
    <attribute name="name" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">The alarm definition may be named.</documentation>
    </annotation>
    </attribute>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType">
    <annotation>
    <documentation xml:lang="en">An optional brief description of this alarm definition.</documentation>
    </annotation>
    </attribute>
    </complexType>

    The updated BaseAlarmType defined above is used in the modification below for the "CustomAlarmType" complexType. It is also used later. Add this new type definition after the already defined "ContextMatchType". This segregates what was previously an element definition.

    <complexType name="CustomAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe a custom, algorithmic alarm condition. The algorithm is assumed to return a boolean value: true or false. See AlarmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <element name="InputAlgorithm" type="xtce:InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Algorithm returns a boolean.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    With these two modifications, the new definition complexType for the "AlarmType" can be applied. Replace the existing definition of the AlarmType with the following definition.

    <complexType name="AlarmType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Defines a base schema type used to build up the other data type specific alarm types. The definition includes a count to go into alarm (minViolations – the counts to go out of alarm is the same), a condition style alarm and a custom alarm. See AlarmConditionType, CustomAlgorithmType, BinaryAlarmConditionType, BooleanAlarmType, BinaryContextAlarmType, EnumerationAlarmType, NumericAlarmType, StringAlarmType, TimeAlarmType, TimeAlarmConditionType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <choice minOccurs="0">
    <element name="AlarmConditions" type="xtce:AlarmConditionsType">
    <annotation>
    <documentation xml:lang="en">A MatchCriteria may be specified for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation>
    </annotation>
    </element>
    <element name="CustomAlarm" type="xtce:CustomAlarmType">
    <annotation>
    <documentation xml:lang="en">An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    <attribute name="minViolations" type="xtce:PositiveLongType" default="1">
    <annotation>
    <documentation xml:lang="en">The number of successive instances that meet the alarm conditions for the alarm to trigger. The default is 1.</documentation>
    </annotation>
    </attribute>
    <attribute name="minConformance" type="xtce:PositiveLongType">
    <annotation>
    <documentation xml:lang="en">Optionally specify the number of successive instances that do not meet the alarm conditions to leave the alarm state. If this attribute is not specified, it is treated as being equal to minViolations (symmetric).</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Lastly for this resolution, update some documentation elements. For the existing "ConcernLevelsType" simpleType, replace the documentation annotation with the following:

    <documentation xml:lang="en">Defines six levels: Normal, Watch, Warning, Distress, Critical and Severe. Typical implementations color the "normal" level as green, "warning" level as yellow, and "critical" level as red. These level definitions are used throughout the alarm definitions. Some systems provide a greater fidelity with the additional levels provided here. The "normal" level is not typically needed because "normal" should be construed as none of the concern levels evaluating to true. For cases where definiing "normal" is needed, refer to the specific alarm definition types.</documentation>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Consolidate the proposals for ParameterProperties element

  • Key: XTCE12-467
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The ParameterProperties element has gone down two different paths during the XTCE 1.2 evolution discussions. The results of that have not been captured in the balloted schema.

  • Reported: XTCE 1.1 — Sun, 30 Jul 2017 18:02 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to merge the proposals for ParameterProperties

    There were two different paths proposed for ParameterProperties. One path was to remove the element. The other path made small enhancements. Propose to adopt the changes in a backwards compatible way.

    This means to retain the ParameterProperties element and update the documentation to be more clear. Also, a new proposed attribute named "persistence" is added.

    Replace the existing complexType definition in the schema:

    <complexType name="ParameterPropertiesType" mixed="false">
    <annotation>
    <documentation xml:lang="en">A wrapper for those properties that are unique to telemetry parameters.</documentation>
    </annotation>
    <sequence>
    <element name="SystemName" type="string" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional. Normally used when the database is built in a flat, non-hierarchical format</documentation>
    </annotation>
    </element>
    <element name="ValidityCondition" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional condition that must be true for this Parameter to be valid</documentation>
    </annotation>
    </element>
    <element name="PhysicalAddressSet" type="xtce:PhysicalAddressSetType" minOccurs="0"/>
    <element name="TimeAssociation" type="xtce:TimeAssociationType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This time will override any Default value for TimeAssociation. </documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="dataSource" type="xtce:TelemetryDataSourceType" use="optional"/>
    <attribute name="readOnly" type="boolean" use="optional" default="false">
    <annotation>
    <documentation xml:lang="en">A Parameter marked as 'readOnly' true is constant and non-settable</documentation>
    </annotation>
    </attribute>
    </complexType>

    With this new definition of the type:

    <complexType name="ParameterPropertiesType" mixed="false">
    <annotation>
    <documentation xml:lang="en">Describes extended properties/attributes of Parameter definitions.</documentation>
    </annotation>
    <sequence>
    <element name="SystemName" type="string" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional. Normally used when the database is built in a flat, non-hierarchical format.</documentation>
    </annotation>
    </element>
    <element name="ValidityCondition" type="xtce:MatchCriteriaType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional condition that must be true for this Parameter to be valid.</documentation>
    </annotation>
    </element>
    <element name="PhysicalAddressSet" type="xtce:PhysicalAddressSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">When present, this set of elements describes physical address location(s) of the parameter where it is stored. Typically this is on the data source, although that is not constrained by this schema.</documentation>
    </annotation>
    </element>
    <element name="TimeAssociation" type="xtce:TimeAssociationType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This time will override any Default value for TimeAssociation.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="dataSource" type="xtce:TelemetryDataSourceType" use="optional">
    <annotation>
    <documentation xml:lang="en">This attribute describes the nature of the source entity for which this parameter receives a value. Implementations assign different attributes/properties internally to a parameter based on the anticipated data source.</documentation>
    </annotation>
    </attribute>
    <attribute name="readOnly" type="boolean" use="optional" default="false">
    <annotation>
    <documentation xml:lang="en">A Parameter marked as 'readOnly' true is constant and non-settable. Note that a slight conceptual overlap exists here between the 'dataSource' and this attribute. When the 'dataSource' is 'constant', then 'readOnly' should be 'true'. Application implementations may choose to implicitly enforce this. Some implementations have both concepts of a Parameter that is settable and a Constant in a different part of the data model.</documentation>
    </annotation>
    </attribute>
    <attribute name="persistence" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">A Parameter marked to persist should retain the latest value through resets/restarts to the extent that is possible or defined in the implementation. The net effect is that the initial/default value on a Parameter is only seen once or when the system has a reset to revert to initial/default values.</documentation>
    </annotation>
    </attribute>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Cleanup unused/dead types in XTCE 1.2 proposed schema

  • Key: XTCE12-462
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    During the evolution of XTCE 1.2, some of the type definitions were rendered unused and in some cases were created and later deprecated. In other cases, they were part of an effort that never completed. These should be removed.

  • Reported: XTCE 1.1 — Sat, 29 Jul 2017 18:32 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to remove dead/unused types in the schema before final acceptance

    The following schema types appear to be unused in the current accepted form of the schema. If needed later, they can be restored.

    Remove these entirely from the xsd file:

    <complexType name="TimeAlarmConditionType">
    <complexType name="RangeEnumerationType">
    <complexType name="BinaryAlarmConditionType">
    <complexType name="ArgumentValueAssignmentListType">
    <complexType name="ArgumentValueAssignmentType">

    Also remove the "eventNameKey" that would have been part of the Event Message change, which is otherwise proposed to be deferred at this time:

    <key name="eventNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique event name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:EventMessageSet/*"/>
    <field xpath="@name"/>
    </key>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Fix overuse of FixedIntegerValueType in proposal

  • Key: XTCE12-459
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The FixedIntegerValueType introduced in XTCE 1.2 proposals is quite handy and flexible. In some cases, it was specified where it should not be. Propose to remove it's usage and revert to "long" for the cases of basic size and range specifications.

  • Reported: XTCE 1.1 — Sat, 29 Jul 2017 17:50 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to undo some of the FixedIntegerValueType uses

    This is a useful new type definition in XTCE 1.2 proposals, but slightly overused. In many basic cases of sizing, this causes excess overhead for implementations to need to interpret several forms of integer representation where it is not needed. It is actually clearer to the reader to have just the regular integer base 10 representation.

    Propose to re-adjust the complexType "IntegerValueType" by changing the line from:

    <element name="FixedValue" type="xtce:FixedIntegerValueType"/>

    to

    <element name="FixedValue" type="long"/>

    Also re-adjust the complexType "IntegerRangeType" by changing the lines from:

    <attribute name="minInclusive" type="xtce:FixedIntegerValueType"/>
    <attribute name="maxInclusive" type="xtce:FixedIntegerValueType"/>

    to

    <attribute name="minInclusive" type="long"/>
    <attribute name="maxInclusive" type="long"/>

    Also re-adjust the complexType "IntegerValueType" by changing the line from:

    <element name="FixedValue" type="xtce:FixedIntegerValueType"/>

    to

    <element name="FixedValue" type="long"/>

    Lastly, re-adjust the complexType "IntegerDataType" by changing the line from:

    <attribute name="initialValue" type="xtce:FixedIntegerValueType">

    to

    <attribute name="initialValue" type="long">

    Correspondingly, update the documentation element to also reflect the change to @initialValue:

    <documentation xml:lang="en">Initial value is always given in calibrated form.</documentation>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Some primitive type intentions missed

  • Key: XTCE12-457
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The committee has expressed a desire to avoid code generation of BigInteger and BigDecimal where it does not make sense. Some XSD types do this. Internal types in the XTCE document avoid this and they have been applied to most places where they are needed, but there have been some misses.

  • Reported: XTCE 1.1 — Sat, 29 Jul 2017 16:41 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the misses in the simple types for numbers

    The following resolution contains the type adjustments. Note that the XML form shown for the elements does not take into account the documentation, so if the line is closed here with a "/" character, that is not applied when fixing the element in the schema where there is additional element content to follow (such as documentation).

    In the complexType "AutoInvertType", change the line from:

    <attribute name="badFramesToAutoInvert" type="positiveInteger" default="1024"/>

    to

    <attribute name="badFramesToAutoInvert" type="xtce:PositiveLongType" default="1024"/>

    In the complexType "ContainerSegmentRefEntryType", change the lines from:

    <attribute name="order" type="positiveInteger"/>
    <attribute name="sizeInBits" type="positiveInteger" use="required"/>

    to

    <attribute name="order" type="xtce:PositiveLongType"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required"/>

    In the complexType "FixedFrameStreamType", change the line from:

    <attribute name="syncApertureInBits" type="nonNegativeInteger" default="0"/>

    to

    <attribute name="syncApertureInBits" type="xtce:NonNegativeLongType" default="0"/>

    In the complexType "FlagType", change the line from:

    <attribute name="flagSizeInBits" type="positiveInteger" default="6"/>

    to

    <attribute name="flagSizeInBits" type="xtce:PositiveLongType" default="6"/>

    In the complexType "InterlockType", change the line from:

    <attribute name="verificationProgressPercentage" type="decimal"/>

    to

    <attribute name="verificationProgressPercentage" type="double"/>

    In the complexType "OnPeriodicRateTriggerType", change the line from:

    <attribute name="fireRateInSeconds" type="decimal" use="required"/>

    to

    <attribute name="fireRateInSeconds" type="double" use="required"/>

    In the complexType name="ParameterSegmentRefEntryType", change the lines from:

    <attribute name="order" type="positiveInteger"/>
    <attribute name="sizeInBits" type="positiveInteger" use="required"/>

    to

    <attribute name="order" type="xtce:PositiveLongType"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required"/>

    In the complexType "StreamSegmentEntryType", change the lines from:

    <attribute name="order" type="positiveInteger"/>
    <attribute name="sizeInBits" type="positiveInteger" use="required"/>

    to

    <attribute name="order" type="xtce:PositiveLongType"/>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required"/>

    In the complexType "SyncPatternType", change the lines from:

    <attribute name="bitLocationFromStartOfContainer" type="integer" default="0"/>
    <attribute name="maskLengthInBits" type="positiveInteger"/>
    <attribute name="patternLengthInBits" type="positiveInteger" use="required"/>

    to

    <attribute name="bitLocationFromStartOfContainer" type="long" default="0"/>
    <attribute name="maskLengthInBits" type="xtce:PositiveLongType"/>
    <attribute name="patternLengthInBits" type="xtce:PositiveLongType" use="required"/>

    In the complexType "SyncStrategyType", change the lines from:

    <attribute name="verifyToLockGoodFrames" type="nonNegativeInteger" default="4"/>
    <attribute name="checkToLockGoodFrames" type="nonNegativeInteger" default="1"/>
    <attribute name="maxBitErrorsInSyncPattern" type="nonNegativeInteger" default="0"/>

    to

    <attribute name="verifyToLockGoodFrames" type="xtce:NonNegativeLongType" default="4"/>
    <attribute name="checkToLockGoodFrames" type="xtce:NonNegativeLongType" default="1"/>
    <attribute name="maxBitErrorsInSyncPattern" type="xtce:NonNegativeLongType" default="0"/>

    In the complexType "TriggerSetType", change the line from:

    <attribute name="triggerRate" type="nonNegativeInteger" use="optional" default="1"/>

    to

    <attribute name="triggerRate" type="xtce:NonNegativeLongType" use="optional" default="1"/>

    In the complexType "ParameterInstanceRefType", change the line from:

    <attribute name="instance" type="integer" default="0"/>

    to

    <attribute name="instance" type="long" default="0"/>

    In the complexType "ChangeValueType", change the line from:

    <attribute name="value" type="decimal" use="required"/>

    to

    <attribute name="value" type="double" use="required"/>

    In the complexType "IntegerDataType", change the line from:

    <attribute name="sizeInBits" type="positiveInteger" default="32"/>

    to

    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="32"/>

    In the complexType "ByteType", change the line from:

    <attribute name="byteSignificance" type="nonNegativeInteger" use="required"/>

    to

    <attribute name="byteSignificance" type="xtce:NonNegativeLongType" use="required"/>

    In the complexType "CRCType", change the line from:

    <attribute name="bitsFromReference" type="nonNegativeInteger"/>

    to

    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType"/>

    In the complexType "IntegerDataEncodingType", change the lines from:

    <attribute name="sizeInBits" type="positiveInteger" default="8"/>
    <attribute name="changeThreshold" type="nonNegativeInteger" use="optional">

    to

    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="8"/>
    <attribute name="changeThreshold" type="xtce:NonNegativeLongType" use="optional">

    In the complexType "LeadingSizeType", change the line from:

    <attribute name="sizeInBitsOfSizeTag" type="positiveInteger" default="16"/>

    to

    <attribute name="sizeInBitsOfSizeTag" type="xtce:PositiveLongType" default="16"/>

    In the complexType "ParityType", change the line from:

    <attribute name="bitsFromReference" type="nonNegativeInteger" use="required"/>

    to

    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType" use="required"/>

    In the complexType "SplinePointType", change the line from:

    <attribute name="order" type="positiveInteger" default="1"/>

    to

    <attribute name="order" type="xtce:NonNegativeLongType" default="1"/>

    In the complexType "ValueEnumerationType", change the lines from:

    <attribute name="value" type="integer" use="required"/>
    <attribute name="maxValue" type="integer">

    to

    <attribute name="value" type="long" use="required"/>
    <attribute name="maxValue" type="long">

    In the complexType "DiscreteLookupType", change the line from:

    <attribute name="value" type="integer" use="required"/>

    to

    <attribute name="value" type="long" use="required"/>

    In the simpleType "FloatSizeInBitsType", change the line from:

    <restriction base="positiveInteger">

    to

    <restriction base="xtce:NonNegativeLongType">

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Correct missed Argument Type updates for argumentRef versus parameterRef when calling out other parameters/arguments

  • Key: XTCE12-482
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Multiple issues have been raised regarding the need to correct the schema where Arguments get ArgumentTypes but oversharing of the Parameter structure caused Arguments to only be able to make references to Parameters and not other Arguments, which is needed in the commanding definitions.

    For instance, when specifying a DynamicValue, only a ParameterInstanceRef could be aimed at. This was confusing at best. Due to the way XSD works, it seems that a number of additional Argument specific types need to be created to clean this up.

  • Reported: XTCE 1.1 — Sat, 9 Sep 2017 18:17 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the Argument Type structures for proper argumentRef and parameterRef support

    This is something of a major issue and it took significant effort from the team to get all of this lined up. This resolution is quite large, but easy to apply.

    I considered splitting it up further, but taking pieces out individually would make for an invalid schema definition.

    The first change occurs in the replacement of the BaseDataType in order to add more descriptive annotations.

    Before:

    <complexType name="BaseDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An abstract type used by within the schema to derive other data types by the ground system. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="UnitSet" type="xtce:UnitSetType" minOccurs="0"/>
    <choice minOccurs="0">
    <element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType"/>
    <element name="FloatDataEncoding" type="xtce:FloatDataEncodingType"/>
    <element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType"/>
    <element name="StringDataEncoding" type="xtce:StringDataEncodingType"/>
    </choice>
    </sequence>
    <attribute name="baseType" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition. </documentation>
    <appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations. </appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BaseDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An abstract schema type used by within the schema to derive the other simple/primitive engineering form data types: BooleanDataType, BinaryDataType, StringDataType, EnumeratedDataType, FloatDataType and IntegerDataType. The encoding elements are optional because they describe the raw wire encoded form of the data type. Encoding is only necessary when the type is telemetered in some form. Local variables and derived typically do not require encoding.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="UnitSet" type="xtce:UnitSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">When appropriate, describe the units of measure that are represented by this parameter value.</documentation>
    </annotation>
    </element>
    <choice minOccurs="0">
    <element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Binary encoding is typically a "pass through" raw encoding form where one of the more common encodings is not required for the parameter. A custom transformation capability is available if needed.</documentation>
    </annotation>
    </element>
    <element name="FloatDataEncoding" type="xtce:FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Float encoding is a common encoding where the raw binary is in a form that gets interpreted as a decimal numeric value.</documentation>
    </annotation>
    </element>
    <element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Integer encoding is a common encoding where the raw binary is in a form that gets interpreted as an integral value, either signed or unsigned.</documentation>
    </annotation>
    </element>
    <element name="StringDataEncoding" type="xtce:StringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">String encoding is a common encoding where the raw binary is in a form that gets interpreted as a character sequence.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    <attribute name="baseType" type="xtce:NameReferenceType">
    <annotation>
    <appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations.</appinfo>
    <documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    For better Argument support in the CommandMetaData, there needs to be a new ArgumentBaseDataType.

    Before (does not exist) - add after BaseDataType:

    <complexType name="ArgumentBaseDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to BaseDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="UnitSet" type="xtce:UnitSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">When appropriate, describe the units of measure that are represented by this argument value.</documentation>
    </annotation>
    </element>
    <choice minOccurs="0">
    <element name="BinaryDataEncoding" type="xtce:ArgumentBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Binary encoding is typically a "pass through" raw encoding form where one of the more common encodings is not required for the argument. A custom transformation capability is available if needed.</documentation>
    </annotation>
    </element>
    <element name="FloatDataEncoding" type="xtce:FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Float encoding is a common encoding where the raw binary is in a form that gets interpreted as a decimal numeric value.</documentation>
    </annotation>
    </element>
    <element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Integer encoding is a common encoding where the raw binary is in a form that gets interpreted as an integral value, either signed or unsigned.</documentation>
    </annotation>
    </element>
    <element name="StringDataEncoding" type="xtce:ArgumentStringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">String encoding is a common encoding where the raw binary is in a form that gets interpreted as a character sequence.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    <attribute name="baseType" type="xtce:NameReferenceType">
    <annotation>
    <appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations.</appinfo>
    <documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next, update the BinaryDataEncodingType to add improved annotations.

    Before:

    <complexType name="BinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For binary data or for integer, float, string, or time data that is not in any of the known encoding formats. For any data that is not encoded in any of the known integer, float, string, or time data formats use a To/From transform algorithm.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="SizeInBits" type="xtce:IntegerValueType"/>
    <element name="FromBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to convert binary data to an application data type</documentation>
    </annotation>
    </element>
    <element name="ToBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to convert binary data from an application data type to binary data</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe binary data that is unmolested in the decoding/encoding or cannot be represented in any of the other data encoding formats. Optionally use the FromBinaryTransformAlgorithm and ToBinaryTransformAlgorithm element to describe the transformation process. See InputAlgorithmType for the transformation structure.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="SizeInBits" type="xtce:IntegerValueType">
    <annotation>
    <documentation xml:lang="en">Number of bits this value occupies on the stream being encoded/decoded.</documentation>
    </annotation>
    </element>
    <element name="FromBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to convert binary data to an application data type</documentation>
    </annotation>
    </element>
    <element name="ToBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to convert binary data from an application data type to binary data</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    For improved Argument support, a new ArgumentBinaryDataEncodingType is needed.

    Before (does not exist) - add before BinaryDataEncodingType:

    <complexType name="ArgumentBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Identical to BinaryDataEncodingType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="SizeInBits" type="xtce:ArgumentIntegerValueType">
    <annotation>
    <documentation xml:lang="en">Number of bits this value occupies on the stream being encoded/decoded.</documentation>
    </annotation>
    </element>
    <element name="FromBinaryTransformAlgorithm" type="xtce:ArgumentInputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to convert binary data to an application data type</documentation>
    </annotation>
    </element>
    <element name="ToBinaryTransformAlgorithm" type="xtce:ArgumentInputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Used to convert binary data from an application data type to binary data</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    A previous mistake was made in the definition of FloatSizeInBitsType where the size in bits could be 0, which makes no sense.

    Before:

    <simpleType name="FloatSizeInBitsType">
    <restriction base="xtce:NonNegativeLongType">
    <enumeration value="32"/>
    <enumeration value="64"/>
    <enumeration value="128"/>
    </restriction>
    </simpleType>

    After:

    <simpleType name="FloatSizeInBitsType">
    <restriction base="xtce:PositiveLongType">
    <enumeration value="32"/>
    <enumeration value="64"/>
    <enumeration value="128"/>
    </restriction>
    </simpleType>

    Adjust the backwards compatible SizeInBits for StringDataEncoding elements and make the choice a sequence with optional on the termination and leading size:

    Before:

    <complexType name="SizeInBitsType">
    <choice>
    <element name="Fixed">
    <complexType>
    <sequence>
    <element name="FixedValue" type="long"/>
    </sequence>
    </complexType>
    </element>
    <element name="TerminationChar" type="hexBinary" default="00">
    <annotation>
    <documentation xml:lang="en">Like C strings, they are terminated with a special string, usually a null character.</documentation>
    </annotation>
    </element>
    <element name="LeadingSize" type="xtce:LeadingSizeType"/>
    </choice>
    </complexType>

    After:

    <complexType name="SizeInBitsType">
    <sequence>
    <element name="Fixed">
    <annotation>
    <documentation xml:lang="en">This is the simplest case of a string data type where the encoding size of the string does not change.</documentation>
    </annotation>
    <complexType>
    <sequence>
    <element name="FixedValue" type="xtce:PositiveLongType">
    <annotation>
    <documentation xml:lang="en">Size in bits of this string data type for both the memory allocation in the implementing software and also the size in bits for this parameter when it appears in a container.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>
    </element>
    <element name="TerminationChar" type="hexBinary" default="00" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The termination character that represents the end of the string contents. For C and most strings, this is null (00), which is the default.</documentation>
    </annotation>
    </element>
    <element name="LeadingSize" type="xtce:LeadingSizeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">In some string implementations, the size of the string contents (not the memory allocation size) is determined by a leading numeric value. This is sometimes referred to as Pascal strings. If a LeadingSize is specified, then the TerminationChar element does not have a functional meaning.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Update the StringDataEncodingType to improve and clarify the annotation, taking backwards compatibility into account:

    Before:

    <complexType name="StringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe common encodings of string data: UTF-8 and UTF-16. See StringDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <choice>
    <element name="SizeInBits" type="xtce:SizeInBitsType">
    <annotation>
    <documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
    </annotation>
    </element>
    <element name="Variable" type="xtce:VariableStringType">
    <annotation>
    <documentation xml:lang="en">A variable length string may change lengths between samples.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="StringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe common encodings of string data: UTF-8 and UTF-16. See StringDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <choice>
    <element name="SizeInBits" type="xtce:SizeInBitsType">
    <annotation>
    <documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
    </annotation>
    </element>
    <element name="Variable" type="xtce:VariableStringType">
    <annotation>
    <documentation xml:lang="en">Variable length strings are those where the space occupied in a container can vary. If the string has variable content but occupies the same amount of space when encoded should use the SizeInBits element. Specification of a variable length string needs to consider that the implementation needs to allocate space to store the string. Specify the maximum possible length of the string data type for memory purposes and also specify the bit size of the string to use in containers with the dynamic elements.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8">
    <annotation>
    <documentation xml:lang="en">The character set encoding of this string data type.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    For improved Argument support, add new ArgumentStringDataEncodingType before StringDataEncodingType.

    New:

    <complexType name="ArgumentStringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Identical to StringDataEncodingType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <choice>
    <element name="SizeInBits" type="xtce:SizeInBitsType">
    <annotation>
    <documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
    </annotation>
    </element>
    <element name="Variable" type="xtce:ArgumentVariableStringType">
    <annotation>
    <documentation xml:lang="en">Variable length strings are those where the space occupied in a container can vary. If the string has variable content but occupies the same amount of space when encoded should use the SizeInBits element. Specification of a variable length string needs to consider that the implementation needs to allocate space to store the string. Specify the maximum possible length of the string data type for memory purposes and also specify the bit size of the string to use in containers with the dynamic elements.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8">
    <annotation>
    <documentation xml:lang="en">The character set encoding of this string data type.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Update VariableStringType to add annotations and fix the choice to sequence with optional termination and leading size. Also a maxSizeInBits attribute is needed with the clarification for users.

    Before:

    <complexType name="VariableStringType">
    <annotation>
    <documentation xml:lang="en">Describe a variable string whose length may change between samples.</documentation>
    </annotation>
    <choice>
    <element name="LeadingSize" type="xtce:LeadingSizeType"/>
    <element name="DynamicValue" type="xtce:DynamicValueType"/>
    <element name="TerminationChar" type="hexBinary"/>
    <element name="DiscreteLookupList" type="xtce:DiscreteLookupListType"/>
    </choice>
    </complexType>

    After:

    <complexType name="VariableStringType">
    <annotation>
    <documentation xml:lang="en">Describe a variable string whose length may change between samples.</documentation>
    </annotation>
    <sequence>
    <choice>
    <element name="DynamicValue" type="xtce:DynamicValueType">
    <annotation>
    <documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter.</documentation>
    </annotation>
    </element>
    <element name="DiscreteLookupList" type="xtce:DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter and selecting a specified value based on tests of the value of that parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="LeadingSize" type="xtce:LeadingSizeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">In some string implementations, the size of the string contents (not the memory allocation size) is determined by a leading numeric value. This is sometimes referred to as Pascal strings. If a LeadingSize is specified, then the TerminationChar element does not have a functional meaning.</documentation>
    </annotation>
    </element>
    <element name="TerminationChar" type="hexBinary" default="00" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The termination character that represents the end of the string contents. For C and most strings, this is null (00), which is the default.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="maxSizeInBits" type="xtce:PositiveLongType" use="required">
    <annotation>
    <documentation xml:lang="en">The upper bound of the size of this string data type so that the implementation can reserve/allocate enough memory to capture all reported instances of the string.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Again, for improved Argument support, a new ArgumentVariableStringType needs to be added before VariableStringType.

    New:

    <complexType name="ArgumentVariableStringType">
    <annotation>
    <documentation>Identical to VariableStringType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <choice>
    <element name="DynamicValue" type="xtce:ArgumentDynamicValueType">
    <annotation>
    <documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter or argument.</documentation>
    </annotation>
    </element>
    <element name="DiscreteLookupList" type="xtce:ArgumentDiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter or argument and selecting a specified value based on tests of the value of that parameter or argument.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="LeadingSize" type="xtce:LeadingSizeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">In some string implementations, the size of the string contents (not the memory allocation size) is determined by a leading numeric value. This is sometimes referred to as Pascal strings. If a LeadingSize is specified, then the TerminationChar element does not have a functional meaning.</documentation>
    </annotation>
    </element>
    <element name="TerminationChar" type="hexBinary" default="00" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The termination character that represents the end of the string contents. For C and most strings, this is null (00), which is the default.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="maxSizeInBits" type="xtce:PositiveLongType" use="required">
    <annotation>
    <documentation xml:lang="en">The upper bound of the size of this string data type so that the implementation can reserve/allocate enough memory to capture all reported instances of the string.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Boolean Argument/Parameter Info:

    The existing BooleanDataType gets improved annotations first.

    Before:

    <complexType name="BooleanDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Contains a boolean value</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial value is always given in calibrated form. </documentation>
    <appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo>
    </annotation>
    </attribute>
    <attribute name="oneStringValue" type="string" default="True"/>
    <attribute name="zeroStringValue" type="string" default="False"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BooleanDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing a boolean data type which has two values only: ‘True’ (1) or ‘False’ (0). The values one and zero may be mapped to a specific string using the attributes oneStringValue and zeroStringValue. This type is a simplified form of the EnumeratedDataType. See BaseDataType, BooleanParameterType and BooleanArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <attribute name="initialValue" type="string">
    <annotation>
    <appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
    </annotation>
    </attribute>
    <attribute name="oneStringValue" type="string" default="True">
    <annotation>
    <documentation xml:lang="en">Enumeration string representing the 1 value, with the default being 'True'.</documentation>
    </annotation>
    </attribute>
    <attribute name="zeroStringValue" type="string" default="False">
    <annotation>
    <documentation xml:lang="en">Enumeration string representing the 0 value, with the default being 'False'.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    For improved Argument support, a new ArgumentBooleanDataType is added.

    Before (does not exist) - add before BooleanDataType:

    <complexType name="ArgumentBooleanDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to BooleanDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <attribute name="initialValue" type="string">
    <annotation>
    <appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
    </annotation>
    </attribute>
    <attribute name="oneStringValue" type="string" default="True">
    <annotation>
    <documentation xml:lang="en">Enumeration string representing the 1 value, with the default being 'True'.</documentation>
    </annotation>
    </attribute>
    <attribute name="zeroStringValue" type="string" default="False">
    <annotation>
    <documentation xml:lang="en">Enumeration string representing the 0 value, with the default being 'False'.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    The BooleanDataType is used in the BooleanParameterType, so improve the annotation there as well.

    Before:

    <complexType name="BooleanParameterType">
    <complexContent>
    <extension base="xtce:BooleanDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:BooleanAlarmType" minOccurs="0"/>
    <element name="ContextAlarmList" type="xtce:BooleanContextAlarmListType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BooleanParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a boolean parameter type which has two values only: ‘True’ (1) or ‘False’ (0). The values one and zero may be mapped to a specific string using the attributes oneStringValue and zeroStringValue. This type is a simplified form of the EnumeratedDataType. See IntegerDataEncoding and BooleanDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BooleanDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:BooleanAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optionally describe an alarm monitoring specification that is effective whenever a contextual alarm definition does not take precedence.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:BooleanContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optionally describe one or more alarm monitoring specifications that are effective whenever a contextual match definition evaluates to true. The first match that evaluates to true takes precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Update the BooleanArgumentType to incorporate the annotation and utilize the new ArgumentBooleanDataType.

    Before:

    <complexType name="BooleanArgumentType">
    <complexContent>
    <extension base="xtce:BooleanDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="BooleanArgumentType">
    <annotation>
    <documentation xml:lang="en">Defines a boolean argument type which has two values only: ‘True’ (1) or ‘False’ (0). The values one and zero may be mapped to a specific string using the attributes oneStringValue and zeroStringValue. This type is a simplified form of the EnumeratedDataType. See IntegerDataEncoding and BooleanDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBooleanDataType"/>
    </complexContent>
    </complexType>

    Enumerated Argument/Parameter Info:

    The existing EnumeratedDataType first gets improved annotations.

    Before:

    <complexType name="EnumeratedDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Contains an enumerated value - a value that has both an integral and a string representation.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <sequence>
    <element name="EnumerationList" type="xtce:EnumerationListType"/>
    </sequence>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial value is always given in calibrated form.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="EnumeratedDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Describes an enumerated parameter type. The enumeration list consists of label/value pairs. See EnumerationListType, EnumeratedParameterType and EnumeratedArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <sequence>
    <element name="EnumerationList" type="xtce:EnumerationListType">
    <annotation>
    <documentation xml:lang="en">Unordered list of label/value pairs where values cannot be duplicated.</documentation>
    <appinfo>Check that values do not overlap in the mappings.</appinfo>
    </annotation>
    </element>
    </sequence>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Use the label, it must be in the enumeration list to be valid.</documentation>
    <appinfo>Label must be in the enumeration list to be valid.</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    To incorporate the improved Argument support, a new ArgumentEnumeratedDataType is now needed.

    Before (does not exist) - add before EnumeratedDataType:

    <complexType name="ArgumentEnumeratedDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to EnumeratedDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="EnumerationList" type="xtce:EnumerationListType">
    <annotation>
    <documentation xml:lang="en">Unordered list of label/value pairs where values cannot be duplicated.</documentation>
    <appinfo>Check that values do not overlap in the mappings.</appinfo>
    </annotation>
    </element>
    </sequence>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Use the label, it must be in the enumeration list to be valid.</documentation>
    <appinfo>Label must be in the enumeration list to be valid.</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next update the EnumeratedParameterType to improve the annotation. This is where the EnumeratedDataType is used.

    Before:

    <complexType name="EnumeratedParameterType">
    <complexContent>
    <extension base="xtce:EnumeratedDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:EnumerationAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state. The default definition applies when there are no context alarm definitions or all the context alarm definitions evaluate to false in their matching criteria.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:EnumerationContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state when another parameter and value combination evaluates to true using the described matching criteria.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="EnumeratedParameterType">
    <annotation>
    <documentation xml:lang="en">Describe an enumerated parameter type. The enumeration list consists of label/value pairs. See EnumerationListType, IntegerDataEncodingType and EnumeratedDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:EnumeratedDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:EnumerationAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state. The default definition applies when there are no context alarm definitions or all the context alarm definitions evaluate to false in their matching criteria.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:EnumerationContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state when another parameter and value combination evaluates to true using the described matching criteria.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    To utilize the new ArgumentEnumeratedDataType, update the EnumeratedArgumentType and improve the annotations.

    Before:

    <complexType name="EnumeratedArgumentType">
    <complexContent>
    <extension base="xtce:EnumeratedDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="EnumeratedArgumentType">
    <annotation>
    <documentation xml:lang="en">Describes an enumerated argument type. The enumeration list consists of label/value pairs. See EnumerationListType, IntegerDataEncodingType and EnumeratedDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentEnumeratedDataType"/>
    </complexContent>
    </complexType>

    Binary Argument/Parameter Info:

    Next improve the annotations on the BinaryDataType.

    Before:

    <complexType name="BinaryDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Contains an arbitrarily large binary value </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <attribute name="initialValue" type="hexBinary">
    <annotation>
    <documentation xml:lang="en">Extra bits are truncated from the MSB (leftmost)</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BinaryDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing a binary data engineering/calibrated type (often called “blob type”). The binary data may be of fixed or variable length, and has an optional encoding and decoding algorithm that may be defined to transform the data between space and ground. See BaseDataType, BinaryParameterType and BinaryArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <attribute name="initialValue" type="hexBinary">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Extra bits are truncated from the MSB (leftmost).</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Then add a new ArgumentBinaryDataType, again for improved support for Arguments in the schema.

    Before (does not exist) - add before BinaryDataType:

    <complexType name="ArgumentBinaryDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to BinaryDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <attribute name="initialValue" type="hexBinary">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Extra bits are truncated from the MSB (leftmost).</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next update the BinaryParameterType for improved annotation.

    Before:

    <complexType name="BinaryParameterType">
    <complexContent>
    <extension base="xtce:BinaryDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:AlarmType" minOccurs="0"/>
    <element name="BinaryContextAlarmList" type="xtce:BinaryContextAlarmListType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BinaryParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a binary engineering/calibrated parameter type (sometimes called a “blob type”). It may be of fixed or variable length, and has an optional encoding and decoding algorithm that may be defined to transform the data between space and ground. See BinaryDataEncodingType, IntegerValueType, InputAlgorithmType and BinaryDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BinaryDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:BinaryAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optionally describe an alarm monitoring specification that is effective whenever a contextual alarm definition does not take precedence.</documentation>
    </annotation>
    </element>
    <element name="BinaryContextAlarmList" type="xtce:BinaryContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optionally describe one or more alarm monitoring specifications that are effective whenever a contextual match definition evaluates to true. The first match that evaluates to true takes precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Then update the BinaryArgumentType to utilize the new ArgumentBinaryDataType created above and improve the annotations.

    Before:

    <complexType name="BinaryArgumentType">
    <complexContent>
    <extension base="xtce:BinaryDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="BinaryArgumentType">
    <annotation>
    <documentation xml:lang="en">Defines a binary engineering/calibrated argument type (often called “blob type”). The binary data may be of fixed or variable length, and has an optional encoding and decoding algorithm that may be defined to transform the data between space and ground. See BinaryDataEncodingType, IntegerValueType, InputAlgorithmType, and BinaryDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBinaryDataType"/>
    </complexContent>
    </complexType>

    Prior to the BooleanAlarmType, add a new BinaryAlarmType that was missed in previous resolutions.

    New:

    <complexType name="BinaryAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe alarm conditions specific to the binary data type, extends the basic AlarmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType"/>
    </complexContent>
    </complexType>

    Integer Argument/Parameter Info:

    Improve the annotations for the IntegerDataType.

    Before:

    <complexType name="IntegerDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Contains an integral value</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NumericDataType">
    <sequence>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range bounds the universe of possible values this Parameter may have.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:IntegerRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="long">
    <annotation>
    <documentation xml:lang="en">Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="32"/>
    <attribute name="signed" type="boolean" default="true"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="IntegerDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Describe an integer engineering/calibrated data type. Several encodings are supported. See BaseDataType, IntegerParameterType and IntegerArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this parameter. Not to be construed as an alarm definition, violations of the valid range make a parameter value "unreasonable", as opposed to reasonable to be reported, but in a state which should be of concern.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:IntegerRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="long">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    <attribute name="signed" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">Flag indicating if the engineering/calibrated data type used should support signed representation. This should not be confused with the encoding type for the raw value. The default is true.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Add a new ArgumentIntegerDataType to improve Argument support in the schema.

    Before (does not exist) - add before IntegerDataType:

    <complexType name="ArgumentIntegerDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to IntegerDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this argument. This typically serves to bound user inputs.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:IntegerRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="xtce:FixedIntegerValueType">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    <attribute name="signed" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">Flag indicating if the engineering/calibrated data type used should support signed representation. This should not be confused with the encoding type for the raw value. The default is true.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    DO NOTHING for the annotations for the IntegerParameterType that uses the IntegerDataType. Already updated in a previous resolution.

    Existing:

    <complexType name="IntegerParameterType">
    <annotation>
    <documentation xml:lang="en">Describe an integer parameter type. Several are supported. Calibrated integer to integer relationships should be described with this data type. Use the integer data encoding to define calibrators. Joins float as one of the numerics. See IntegerDataEncoding and IntegerDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:IntegerDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    DO NOT MODIFY

    Update the IntegerArgumentType to improve the annotation and use the new ArgumentIntegerDataType from above.

    Before:

    <complexType name="IntegerArgumentType">
    <complexContent>
    <extension base="xtce:IntegerDataType">
    <sequence>
    <element name="ValidRangeSet" type="xtce:ValidIntegerRangeSetType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="IntegerArgumentType">
    <annotation>
    <documentation xml:lang="en">Describes an integer argument type. Several encodings supported. Calibrated integer to integer relationships should be described with this data type. Use the integer data encoding to define calibrators. Joins float as one of the numerics. See IntegerDataEncoding and IntegerDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentIntegerDataType">
    <sequence>
    <element name="ValidRangeSet" type="xtce:ValidIntegerRangeSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Provides additional platform/program specific ranging information.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Float Argument/Parameter Info:

    Update the annotations on the FloatDataType. This also effectively deprecates NumericDataType as it is removed from Float and Integer here and in the resolution above.

    Before:

    <complexType name="FloatDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Contains a floating point value</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NumericDataType">
    <sequence>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range bounds the universe of possible values this Parameter may have.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Initial value is always given in calibrated form</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="FloatDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing a floating point engineering/calibrated data type. Several encodings are supported. Calibrated integer to float relationships should be described with this data type. Use the data encoding to define calibrators. Joins integer as one of the numerics. See BaseDataType, FloatParameterType and FloatArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this parameter. Not to be construed as an alarm definition, violations of the valid range make a parameter value "unreasonable", as opposed to reasonable to be reported, but in a state which should be of concern.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Initial value is always given in calibrated form</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    For improved Argument support, add a new ArgumentFloatDataType.

    Before (does not exist) - add before FloatDataType:

    <complexType name="ArgumentFloatDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to FloatDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="ToString" type="xtce:ToStringType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
    </annotation>
    </element>
    <element name="ValidRange" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this argument.</documentation>
    </annotation>
    <complexType>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    <attribute name="initialValue" type="double">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Now update the annotations on the FloatParameterType that uses the FloatDataType.

    Before:

    <complexType name="FloatParameterType">
    <complexContent>
    <extension base="xtce:FloatDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0"/>
    <element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="FloatParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a floating point parameter type. Several encodings are supported. Calibrated integer to float relationships should be described with this data type. Use the data encoding to define calibrators. Joins integer as one of the numerics. See FloatDataEncodingType, IntegerDataEncodingType and FloatDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:FloatDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Update the FloatArgumentType to use the new ArgumentFloatDataType and improve the annotations.

    Before:

    <complexType name="FloatArgumentType">
    <complexContent>
    <extension base="xtce:FloatDataType">
    <sequence>
    <element name="ValidRangeSet" type="xtce:ValidFloatRangeSetType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="FloatArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe a floating point argument type. Several encodings are supported. Calibrated integer to float relationships should be described with this data type. Use the data encoding to define calibrators. Joins integer as one of the numerics. See FloatDataEncodingType, IntegerDataEncodingType and FloatDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentFloatDataType">
    <sequence>
    <element name="ValidRangeSet" type="xtce:ValidFloatRangeSetType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Provides additional platform/program specific ranging information.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    With the change to better tailor the Integer and Float specific data types, the NumericDataType is now no longer used and can be removed from the schema.

    SPECIAL: Remove now the NumericDataType and it is no longer used.

    String Argument/Parameter Info:

    Significant refactoring and clarification have been made to the String defintions. First update the StringDataType annotations.

    Before:

    <complexType name="StringDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Contains a String Value</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <sequence>
    <element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/>
    </sequence>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \",
    , etc.) escape sequences.</documentation>
    </annotation>
    </attribute>
    <attribute name="restrictionPattern" type="string">
    <annotation>
    <documentation xml:lang="en">restriction pattern is a regular expression</documentation>
    </annotation>
    </attribute>
    <attribute name="characterWidth" type="xtce:CharacterWidthType"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="StringDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Defines a base schema type for StringParameterType and StringArgumentType, adding initial value, restriction pattern, character width, and size range in characters. The initial value if set is the initial value of all instances of the child types. The restriction pattern is a regular expression enforcing the string value to this pattern. The character width is on the local data type side. And the size range in character restricts the character set. For telemetered values, if the restriction pattern of size range in character is not met, the item is invalid. See BaseDataType, StringParameterType, StringArgumentType, CharacterWidthType and IntegerRangeType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDataType">
    <sequence>
    <element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The size in bits may be greater than or equal to minInclusive. It may be less than or equal to maxInclusive. They both may be set indicating a closed range.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \",
    , etc.) escape sequences.</documentation>
    </annotation>
    </attribute>
    <attribute name="restrictionPattern" type="string">
    <annotation>
    <documentation xml:lang="en">restriction pattern is a regular expression</documentation>
    </annotation>
    </attribute>
    <attribute name="characterWidth" type="xtce:CharacterWidthType"/>
    </extension>
    </complexContent>
    </complexType>

    For improved Argument support, add a new ArgumentStringDataType to the schema.

    Before (does not exist) - add before StringDataType:

    <complexType name="ArgumentStringDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to StringDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseDataType">
    <sequence>
    <element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/>
    </sequence>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \",
    , etc.) escape sequences.</documentation>
    </annotation>
    </attribute>
    <attribute name="restrictionPattern" type="string">
    <annotation>
    <documentation xml:lang="en">restriction pattern is a regular expression</documentation>
    </annotation>
    </attribute>
    <attribute name="characterWidth" type="xtce:CharacterWidthType"/>
    </extension>
    </complexContent>
    </complexType>

    Update the StringParameterType to improve the annotations.

    Before:

    <complexType name="StringParameterType">
    <complexContent>
    <extension base="xtce:StringDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:StringAlarmType" minOccurs="0"/>
    <element name="ContextAlarmList" type="xtce:StringContextAlarmListType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="StringParameterType">
    <annotation>
    <documentation xml:lang="en">Describes a string parameter type. Three forms are supported: fixed length, variable length and variable length using a prefix. See StringDataEncodingType and StringDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:StringDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:StringAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:StringContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Update the StringArgumentType to use the new ArgumentStringDataType and improve the annotations.

    Before:

    <complexType name="StringArgumentType">
    <complexContent>
    <extension base="xtce:StringDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="StringArgumentType">
    <annotation>
    <documentation xml:lang="en">Describes a string parameter type. Three forms are supported: fixed length, variable length and variable length using a prefix. See StringDataEncodingType and StringDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentStringDataType"/>
    </complexContent>
    </complexType>

    Aggregate Argument/Parameter Info:

    Update the annotations for the Aggregate/Structure data type.

    Before:

    <complexType name="AggregateDataType" abstract="true">
    <annotation>
    <documentation>Contains multiple values (as members) of any type</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="MemberList" type="xtce:MemberListType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="AggregateDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing a complex data type analogous to a C-struct. Each field of the data type is called a Member. Each Member is part of the MemberList which forms the list of items to be placed under this data type’s name. The MemberList defines a data block and block’s size is defined by the DataEncodings of each Member’s type reference. The data members are ordered and contiguous in the MemberList element (packed). Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, AggregateParameterType and AggregateArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="MemberList" type="xtce:MemberListType">
    <annotation>
    <documentation xml:lang="en">Ordered list of the members of the aggregate/structure. Members are contiguous.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Improve the annotation content for the AggregateParameterType type.

    Before:

    <complexType name="AggregateParameterType">
    <annotation>
    <documentation xml:lang="en">AggegateParameters are analogous to a C struc, they are an aggregation of related data items. Each of these data items is defined here as a 'Member' </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AggregateDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="AggregateParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a complex data type analogous to a C-struct. Each field of the data type is called a Member. Each Member is part of the MemberList which forms the list of items to be placed under this data type’s name. The MemberList defines a data block and block’s size is defined by the DataEncodings of each Member’s type reference. The data members are ordered and contiguous in the MemberList element (packed). Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, and AggregateDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AggregateDataType"/>
    </complexContent>
    </complexType>

    Improve the annotation content for the AggregateArgumentType type.

    Before:

    <complexType name="AggregateArgumentType">
    <complexContent>
    <extension base="xtce:AggregateDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="AggregateArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe a complex data type analogous to a C-struct. Each field of the data type is called a Member. Each Member is part of the MemberList which forms the list of items to be placed under this data type’s name. The MemberList defines a data block and block’s size is defined by the DataEncodings of each Member’s type reference. The data members are ordered and contiguous in the MemberList element (packed). Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, and AggregateDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AggregateDataType"/>
    </complexContent>
    </complexType>

    Relative Time Argument/Parameter Info:

    DO NOTHING for the annotations for the RelativeTimeDataType that uses the BaseTimeDataType. Already updated in a previous resolution.

    Before:

    <complexType name="RelativeTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseTimeDataType">
    <attribute name="initialValue" type="duration"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    DO NOT MODIFY

    For improved Argument support, add a new ArgumentRelativeTimeDataType.

    Before (does not exist) - add after RelativeTimeDataType:

    <complexType name="ArgumentRelativeTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseTimeDataType">
    <attribute name="initialValue" type="duration"/>
    </extension>
    </complexContent>
    </complexType>

    Improve and clarify the annotations for the RelativeTimeParameterType.

    Before:

    <complexType name="RelativeTimeParameterType">
    <complexContent>
    <extension base="xtce:RelativeTimeDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:TimeAlarmType" minOccurs="0"/>
    <element name="ContextAlarmList" type="xtce:TimeContextAlarmListType" minOccurs="0"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="RelativeTimeParameterType">
    <annotation>
    <documentation xml:lang="en">Describes a relative time parameter type. Relative time parameters are time offsets (e.g. 10 second, 1.24 milliseconds, etc.) See IntegerDataEncodingType, FloatDataEncoding and RelativeTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:RelativeTimeDataType">
    <sequence>
    <element name="DefaultAlarm" type="xtce:TimeAlarmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
    </annotation>
    </element>
    <element name="ContextAlarmList" type="xtce:TimeContextAlarmListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Update the RelativeTimeArgumentType to utilize the new ArgumentRelativeTimeDataType and improve the annotation.

    Before:

    <complexType name="RelativeTimeArgumentType">
    <complexContent>
    <extension base="xtce:RelativeTimeDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="RelativeTimeArgumentType">
    <annotation>
    <documentation xml:lang="en">Describes a relative time argument type. Relative time parameters are time offsets (e.g. 10 second, 1.24 milliseconds, etc.) See IntegerDataEncodingType, FloatDataEncoding and RelativeTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentRelativeTimeDataType"/>
    </complexContent>
    </complexType>

    Absolute Time Argument/Parameter Info:

    Update the BaseTimeDataType to improve annotation and add a previously missed baseType attribute.

    Before:

    <complexType name="BaseTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An abstract type used by within the schema to describe derive other data types by the ground system. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <sequence minOccurs="0">
    <element name="Encoding" type="xtce:EncodingType"/>
    </sequence>
    <sequence minOccurs="0">
    <element name="ReferenceTime" type="xtce:ReferenceTimeType"/>
    </sequence>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="BaseTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An abstract schema type used within the schema to derive other time based data types: RelativeTimeDataType and AbsoluteTimeDataType. An absolute time data type is a telemetered source/destination data type. A data encoding must be set. An optional epoch may be set. Time types are an exception to other primitives because, if the time data type is not telemetered, it still must have a data encoding set. See DataEncodingType, AbsoluteTimeDataType and RelativeTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="Encoding" type="xtce:EncodingType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes how the raw base counts of the time type are encoded/decoded.</documentation>
    </annotation>
    </element>
    <element name="ReferenceTime" type="xtce:ReferenceTimeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes origin (epoch or reference) of this time type.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="baseType" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Extend another absolute or relative time type.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Add a new ArgumentBaseTimeDataType for improved Argument support in the schema.

    Before (does not exist) - add before BaseTimeDataType:

    <complexType name="ArgumentBaseTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Identical to BaseTimeDataType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="Encoding" type="xtce:EncodingType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes how the raw base counts of the time type are encoded/decoded.</documentation>
    </annotation>
    </element>
    <element name="ReferenceTime" type="xtce:ReferenceTimeType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes origin (epoch or reference) of this time type.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="baseType" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Extend another absolute or relative time type.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Update the AbsoluteTimeDataType to improve and clarify the annotation.

    Before:

    <complexType name="AbsoluteTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Used to contain an absolute time. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported.
    </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseTimeDataType">
    <attribute name="initialValue" type="dateTime"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="AbsoluteTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing an absolute time data type. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See AbsoluteTimeParameterType and AbsoluteTimeArgumentType. See AbsouteTimeParameterType, AbsoluteTimeArgumentType and BaseTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseTimeDataType">
    <attribute name="initialValue" type="dateTime">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Add a new ArgumentAbsoluteTimeDataType for improved Argument support in the schema using the new ArgumentBaseTimeDataType.

    Before (does not exist) - add before AbsoluteTimeDataType:

    <complexType name="ArgumentAbsoluteTimeDataType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing an absolute time data type. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See AbsoluteTimeParameterType and AbsoluteTimeArgumentType. See AbsouteTimeParameterType, AbsoluteTimeArgumentType and BaseTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentBaseTimeDataType">
    <attribute name="initialValue" type="dateTime">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Update the annotations on the AbsoluteTimeParameterType.

    Before:

    <complexType name="AbsoluteTimeParameterType">
    <complexContent>
    <extension base="xtce:AbsoluteTimeDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="AbsoluteTimeParameterType">
    <annotation>
    <documentation xml:lang="en">Describe an absolute time parameter type relative to a known epoch (such as TAI). The string representation of this time should use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See TAIType, IntegerDataEncoding and AbsoluteTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AbsoluteTimeDataType"/>
    </complexContent>
    </complexType>

    Update the annotations and apply the new ArgumentAbsoluteTimeDataType to the AbsoluteTimeArgumentType.

    Before:

    <complexType name="AbsoluteTimeArgumentType">
    <complexContent>
    <extension base="xtce:AbsoluteTimeDataType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="AbsoluteTimeArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an absolute time argument type relative to a known epoch (such as TAI). The string representation of this time should use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See TAIType, IntegerDataEncoding and AbsoluteTimeDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArgumentAbsoluteTimeDataType"/>
    </complexContent>
    </complexType>

    Array Argument/Parameter Info:

    Improve the annotations for arrays by updating the ArrayDataTypeType.

    Before:

    <complexType name="ArrayDataTypeType" abstract="true">
    <annotation>
    <documentation xml:lang="en">An array of values of the type referenced in 'arrayTypeRef' and have the number of array dimensions as specified in 'numberOfDimensions' </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="DimensionList" type="xtce:DimensionListType"/>
    </sequence>
    <attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    After:

    <complexType name="ArrayDataTypeType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base schema type for describing an array data type. The number of and size of each dimension is defined in its two child types. See NameReferenceType, ArrayArgumentType and ArrayParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Reference to the data type that represents the type of the elements for this array.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Follow up with improved array annotation by updating the ArrayParameterType type.

    Before:

    <complexType name="ArrayParameterType">
    <annotation>
    <documentation>Describe an array parameter type. The size and number of dimensions are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayDataTypeType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="ArrayParameterType">
    <annotation>
    <documentation xml:lang="en">Describe an array parameter type. The size and number of dimensions are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayDataTypeType">
    <sequence>
    <element name="DimensionList" type="xtce:DimensionListType">
    <annotation>
    <documentation xml:lang="en">Describe the dimensions of this array.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Also update the annotations for the ArrayArgumentType type and take into account the ArgumentDimensionListType added in a previous resolution.

    Before:

    <complexType name="ArrayArgumentType">
    <annotation>
    <documentation>Describe an array argument type. The size and number of dimension are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayDataTypeType"/>
    </complexContent>
    </complexType>

    After:

    <complexType name="ArrayArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an array argument type. The size and number of dimension are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayDataTypeType">
    <sequence>
    <element name="DimensionList" type="xtce:ArgumentDimensionListType">
    <annotation>
    <documentation xml:lang="en">Describe the dimensions of this array.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Now to the ParameterTypeSet and ArgumentTypeSet. Improve the annotations on these lists.

    Before:

    <complexType name="ParameterTypeSetType">
    <annotation>
    <documentation xml:lang="en">Holds the list of parameter type definitions. A Parameter is a description of something that can have a value; it is not the value itself. </documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="StringParameterType" type="xtce:StringParameterType"/>
    <element name="EnumeratedParameterType" type="xtce:EnumeratedParameterType"/>
    <element name="IntegerParameterType" type="xtce:IntegerParameterType"/>
    <element name="BinaryParameterType" type="xtce:BinaryParameterType"/>
    <element name="FloatParameterType" type="xtce:FloatParameterType"/>
    <element name="BooleanParameterType" type="xtce:BooleanParameterType"/>
    <element name="RelativeTimeParameterType" type="xtce:RelativeTimeParameterType"/>
    <element name="AbsoluteTimeParameterType" type="xtce:AbsoluteTimeParameterType"/>
    <element name="ArrayParameterType" type="xtce:ArrayParameterType"/>
    <element name="AggregateParameterType" type="xtce:AggregateParameterType"/>
    </choice>
    </complexType>

    After:

    <complexType name="ParameterTypeSetType">
    <annotation>
    <documentation xml:lang="en">Describe an unordered collection of parameter type definitions. These types named for the engineering/calibrated type of the parameter. See BaseDataType and BaseTimeDataType.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="StringParameterType" type="xtce:StringParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a character string.</documentation>
    </annotation>
    </element>
    <element name="EnumeratedParameterType" type="xtce:EnumeratedParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an enumeration.</documentation>
    </annotation>
    </element>
    <element name="IntegerParameterType" type="xtce:IntegerParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an integer.</documentation>
    </annotation>
    </element>
    <element name="BinaryParameterType" type="xtce:BinaryParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a binary (usually hex represented).</documentation>
    </annotation>
    </element>
    <element name="FloatParameterType" type="xtce:FloatParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a decimal.</documentation>
    </annotation>
    </element>
    <element name="BooleanParameterType" type="xtce:BooleanParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a boolean enumeration.</documentation>
    </annotation>
    </element>
    <element name="RelativeTimeParameterType" type="xtce:RelativeTimeParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a duration in time.</documentation>
    </annotation>
    </element>
    <element name="AbsoluteTimeParameterType" type="xtce:AbsoluteTimeParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an instant in time.</documentation>
    </annotation>
    </element>
    <element name="ArrayParameterType" type="xtce:ArrayParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an array of a primitive type.</documentation>
    </annotation>
    </element>
    <element name="AggregateParameterType" type="xtce:AggregateParameterType">
    <annotation>
    <documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a structure of parameters of other types.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Before:

    <complexType name="ArgumentTypeSetType">
    <annotation>
    <documentation xml:lang="en">Holds the list of argument type definitions. </documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="StringArgumentType" type="xtce:StringArgumentType"/>
    <element name="EnumeratedArgumentType" type="xtce:EnumeratedArgumentType"/>
    <element name="IntegerArgumentType" type="xtce:IntegerArgumentType"/>
    <element name="BinaryArgumentType" type="xtce:BinaryArgumentType"/>
    <element name="FloatArgumentType" type="xtce:FloatArgumentType"/>
    <element name="BooleanArgumentType" type="xtce:BooleanArgumentType"/>
    <element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType"/>
    <element name="AbsoluteTimeArgumentType" type="xtce:AbsoluteTimeArgumentType"/>
    <element name="ArrayArgumentType" type="xtce:ArrayArgumentType"/>
    <element name="AggregateArgumentType" type="xtce:AggregateArgumentType"/>
    </choice>
    </complexType>

    After:

    <complexType name="ArgumentTypeSetType">
    <annotation>
    <documentation xml:lang="en">Describe an unordered collection of argument type definitions. These types named for the engineering/calibrated type of the argument. See BaseDataType and BaseTimeDataType.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="StringArgumentType" type="xtce:StringArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a character string.</documentation>
    </annotation>
    </element>
    <element name="EnumeratedArgumentType" type="xtce:EnumeratedArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an enumeration.</documentation>
    </annotation>
    </element>
    <element name="IntegerArgumentType" type="xtce:IntegerArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an integer.</documentation>
    </annotation>
    </element>
    <element name="BinaryArgumentType" type="xtce:BinaryArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a binary (usually hex represented).</documentation>
    </annotation>
    </element>
    <element name="FloatArgumentType" type="xtce:FloatArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a decimal.</documentation>
    </annotation>
    </element>
    <element name="BooleanArgumentType" type="xtce:BooleanArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a boolean enumeration.</documentation>
    </annotation>
    </element>
    <element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a duration in time.</documentation>
    </annotation>
    </element>
    <element name="AbsoluteTimeArgumentType" type="xtce:AbsoluteTimeArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an instant in time.</documentation>
    </annotation>
    </element>
    <element name="ArrayArgumentType" type="xtce:ArrayArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an array of a primitive type.</documentation>
    </annotation>
    </element>
    <element name="AggregateArgumentType" type="xtce:AggregateArgumentType">
    <annotation>
    <documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a structure of arguments of other types.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    After addition of these changes and the previous few issue resolutions, the following types should be deleted because they are no longer used in the schema:

    FixedValueEntryType (renamed earlier for consistency)
    ArgumentInstanceType (refactored out)
    ArgumentRefEntryType (renamed earlier for consistency)
    ArrayArgumentRefEntryType (renamed earlier for consistency)

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MetaCommandStep argument assignment

  • Key: XTCE12-397
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    MetaCommandStep argument values are assigned using <ArgumentList> / <Argument> elements. Using these elements creates two issues in the XTCE model:

    1. Two different element definitions for <ArgumentList> / <Argument>
      1. <MetaCommandStep> / <ArgumentList> / <Argument>
      2. <MetaCommand> / <ArgumentList> / <Argument>
    2. Two XML implementations of the ArgumentAssignment concept:
      1. <MetaCommandStep> / <ArgumentList> / <Argument>
      2. <BaseMetaCommand> / <ArgumentAssignmentList> / <ArgumentAssignment>

    Recommend replacing the argument assignment elements in <MetaCommandStep> with the elements used for <BaseMetaCommand>.
    This would provide a more unified and descriptive definition.

  • Reported: XTCE 1.1 — Tue, 6 Dec 2016 18:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Use ArgumentAssignmentList

    In the complexType MetaCommandStepType, add the annotation:
    <annotation>
    <documentation>Describe a MetaCommand step, consisting MetaCommand reference and argument list. See MetaCommandStepListType and NameReferenceType.</documentation>
    </annotation>

    and replace the element:
    <element name="ArgumentList" type="xtce:ArgumentValueAssignmentListType" minOccurs="0"/>
    with:
    <element name="ArgumentAssignmentList" type="xtce:ArgumentAssignmentListType" minOccurs="0"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add normal alarm condition or alarm ranges

  • Key: XTCE12-29
  • Legacy Issue Number: 19392
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add a new alarm type to capture sequential ranges to permit a "barber pole" like definition. Reported by Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to create a new AlarmMultiRanges definition in the numeric alarm types

    The new alarm multi-range feature proposal permits users to define multiple alarm ranges in a sequence that goes beyond the more typical "inside" and "outside" range definitions. It can be thought of as a "barber pole" definition.

    Adding support for the "multi-range" feature first requires adding two new complexType elements to the schema. These are:

    <complexType name="MultiRangeType">
    <annotation>
    <documentation xml:lang="en">The alarm multi-range element type permits users to define multiple alarm ranges in a sequence that goes beyond the more typical "inside" and "outside" range definitions. It can be thought of as a "barber pole" definition.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation xml:lang="en">A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch. The most common form used is "outside" and is the default.</documentation>
    </annotation>
    </attribute>
    <attribute name="level" type="xtce:ConcernLevelsType">
    <annotation>
    <documentation xml:lang="en">The level of concern for this alarm definition.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    and:

    <complexType name="AlarmMultiRangesType">
    <annotation>
    <documentation xml:lang="en">Describe any number of alarm ranges, each with its own level (normal, warning, watch, distress, critical, severe) and range form (inside or outside). Ranges may overlap, be disjoint and so forth. Ranges within the value sprectrum non-specified are non-normal. The most severe range level of value within the ranges is the level of the alarm. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <element name="Range" type="xtce:MultiRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe any number of alarm ranges, each with its own level (normal, warning, watch, distress, critical, severe) and range form (inside or outside). Ranges may overlap, be disjoint and so forth. Ranges within the value sprectrum non-specified are non-normal. The most severe range level of value within the ranges is the level of the alarm. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    These two new types are utilized by adding a new element to the complexType NumericAlarmType. This new element definition in the XSD appears after the two existing element definitions and is named AlarmMultiRanges. The updated definition is:

    <complexType name="NumericAlarmType">
    <annotation>
    <documentation xml:lang="en">Describe alarm conditions specific to the numeric data types, extends the basic AlarmType with StaticAlarmRanges and ChangeAlarmRanges. See FloatParameterType and IntegerParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="StaticAlarmRanges" type="xtce:AlarmRangesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value.</documentation>
    </annotation>
    </element>
    <element name="ChangeAlarmRanges" type="xtce:ChangeAlarmRangesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">ChangeAlarmRanges are used to trigger alarms when the parameter value changes by a rate or quantity from a reference.</documentation>
    </annotation>
    </element>
    <element name="AlarmMultiRanges" type="xtce:AlarmMultiRangesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Similar to but more lenient form of StaticAlarmRanges.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Improve FloatRangeType and IntegerRangeType

  • Key: XTCE12-18
  • Legacy Issue Number: 19435
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    IntegerRangeType and FloatRangeType define ranges with attributes. The integer version has two, min/max which are inclusive and the float has four which are both inclusive and exclusive. The float version is particularly “bad” because its four attributes can all be set, or some combination of them, forcing the implementer to quality check that just two are set.

    Another approach would be to provide two attributes: min/max for the value ­ and then a third attribute called “rangeType” or some such to indicate the kind of comparison to be performed: open, closed, open-closed, closed-open indicating whether the values are inclusive or exclusive – one, the other, or both.

  • Reported: XTCE 1.1 — Wed, 28 May 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-72 and resolved in XTCE12-329

    This issue is addressed to the extent that the @rangeForm attribute is now available to cover the inside/outside case. It was decided by the committee not to propose separating the inclusive/exclusive because it would more limit the possible capability for specifying values.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Only single instance of Alarm Condition/Range

  • Key: XTCE12-34
  • Legacy Issue Number: 19393
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add a new alarm type (we know what this means). Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged to XTCE12-29 proposed fix in XTCE12-444

    This issue is accepted but appears to duplicate the needs that are proposed for resolution in XTCE12-29. The specific issue resolution to cover this is XTCE12-444.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Off Alarms

  • Key: XTCE12-50
  • Legacy Issue Number: 19375
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    An off alarm disables a previously defined alarm. It will turn off ALL previously defined alarms at a certain level
    (RED or YELLOW) associated with the specified telemetry parameter. If the alarms themselves can be addressed, it can be configured to turn off individual alarms. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged to XTCE12-29 proposed fix in XTCE12-444

    This issue is accepted and resolved when doing resolutions for the larger XTCE12-29. The specific resolution is that ConcernLevelsType now has a "normal" definition in the enumerations.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

inside/outside alarms not supported

  • Key: XTCE12-72
  • Legacy Issue Number: 14513
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for the case of inner/outer alarm range definition

    Proposal is to update the alarm ranges to permit the user to specify whether or not alarms are in "inner" or "outer" form.

    Add the following types (new) to the types section:

    <simpleType name="RangeFormType">
    <annotation>
    <documentation>Defines whether the defined range between the minimum and maximum is the outside or inside the range being defined. The default, outside matches values less than the minimum and greater than the maximum. Inside matches values between the minimum and maximum.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="outside"/>
    <enumeration value="inside"/>
    </restriction>
    </simpleType>

    <complexType name="BaseAlarmType" abstract="true">
    <annotation>
    <documentation>Supplies an optional non-reference-able name and short description for alarms. Also includes an optional ancillary data for any special local flags, note that these may not necessarily transfer to another recipient of an instance document.</documentation>
    </annotation>
    <sequence>
    <element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0"/>
    </sequence>
    <attribute name="name" type="string"/>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType"/>
    </complexType>

    Replace the AlarmRangesType definition with the definition below. This adds the @rangeForm attribute to the AlarmRangesType, makes it extend BaseAlarmType and provides new documentation for the inside/outside settings:

    <complexType name="AlarmRangesType">
    <annotation>
    <documentation>Describe up to six ranges where either less severe ranges are a subset of more severe ranges (outside), or more severe ranges are a subset of less severe ranges (inside). In both forms, the undefined least severe range is normal. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <element name="WatchRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="WarningRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="DistressRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="CriticalRange" type="xtce:FloatRangeType" minOccurs="0"/>
    <element name="SevereRange" type="xtce:FloatRangeType" minOccurs="0"/>
    </sequence>
    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation>A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ChangeAlarmRates confusing and ambiguous

  • Key: XTCE12-76
  • Legacy Issue Number: 14512
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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 +/-

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged to XTCE12-490 proposed fix in XTCE12-443

    This issue is accepted but was incorporated in the change to XTCE12-490 when the numeric alarm portion of the update was addressed. The specific resolution that captures this issue is XTCE12-443.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

InputOutputAlgorithm@thread optional boolean, should have default of false

  • Key: XTCE12-93
  • Legacy Issue Number: 14495
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    InputOutputAlgorithm@thread optional boolean, should have default of false

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept the recommendation for @thread attribute

    An update is proposed to set the default value of the @thread attribute in the InputOutputAlgorithmType.

    In the complexType InputOutputAlgorithmType, change the thread attribute from:
    <attribute name="thread" type="boolean" use="optional"/>
    to:
    <attribute name="thread" type="boolean" use="optional" default="false"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

The ToString element used in Integer and Float types overlaps with Enumerated types

  • Key: XTCE12-381
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Inside of the ToString element, there are possibilities for making number to string mappings that confuse with the Enumerated Parameter/Argument types. These should be removed and the ToString element simplified to satisfy a tighter purpose.

  • Reported: XTCE 1.1 — Sat, 15 Oct 2016 16:16 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to simplify the ToString element

    This is not backwards compatible with any existing documents that use ToStringType, but simplifies the definition of an appropriate format for a numeric parameter and eliminates the confusion with the EnumeratedDataType that many XTCE users experienced. This proposal also eliminates the NumberToStringType which is only used as the base for ToStringType, when ToStringType added no new elements or attributes. This proposal removes the enumeration labels and unnecessary extra elements in the ToString element. Implementation of this proposal also caused validation errors in the schema, due to a typo in a previous resolution. The change to correct that typo is included here, so that the schema will properly validate.

    Delete the complexType NumberToStringType

    Replace the definition for ToStringType with the following complexType definition:
    <complexType name="ToStringType">
    <sequence>
    <element name="NumberFormat" type="xtce:NumberFormatType" minOccurs="1" maxOccurs="1">
    <annotation>
    <documentation xml:lang="en">This element describes how a numeric value should be represented in engineering/calibrated form. The defaults reflect the most common form.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Change the case of the 'D' in "decimal" to "Decimal" for the default value for attribute numberBase in complexType NumberFormatType
    <attribute name="numberBase" type="xtce:RadixType" use="optional" default="Decimal">

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Mistake in previous resolution for addition of XInclude support

  • Key: XTCE12-441
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    An issue was created as XTCE12-10 regarding the lack of support for the XML Xinclude facility. A proposal passed under XTCE12-308 to add the import and and nillable attribute. This resolution missed the attribute definition needed to enable the location of the XInclude support.

  • Reported: XTCE 1.1 — Sat, 29 Apr 2017 14:33 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to repair the original resolution fix for XTCE12-10

    To finish the definition of the XInclude feature for XTCE, an attribute needs to be added to the complexType xtce:SpaceSystemType.

    The following attribute definition:

    <attribute ref="xml:base"/>

    Should appear immediately after the last attribute in the extension for the complexType. That last attribute is:

    <attribute name="operationalStatus" type="token" use="optional"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Error in unique keys fix in XTCE12-346

  • Key: XTCE12-439
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The revision task force made an error in the resolution of issue XTCE12-15 recorded in subtask XTCE12-346. This error calls out a unique key for the element xtce:CommandMetaData/xtce:ContainerSet attribute @name. This should be xtce:CommandContainerSet.

  • Reported: XTCE 1.1 — Sun, 16 Apr 2017 16:04 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to repair the original resolution fix for XTCE12-15

    In the previous resolution, the wrong element name was specified for the unique keys defined on the @name attributes in the XTCE document.

    The key as balloted and approved in ballot #9 shows the key as:

    <key name="containerNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a container stream name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:ContainerSet/|xtce:CommandMetaData/xtce:ContainerSet/"/>
    <field xpath="@name"/>
    </key>

    This should be revised to:

    <key name="containerNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a container stream name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:ContainerSet/|xtce:CommandMetaData/xtce:CommandContainerSet/"/>
    <field xpath="@name"/>
    </key>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Alternate approach to xs:positiveInteger and xs:nonNegativeInteger

  • Key: XTCE12-431
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The XTCE Schema uses two XSD types that cause issues for code generators. The xs:positiveInteger and xs:nonNegativeInter end up with things like the "BigInteger" class in the generated code mapping, although the ranging capability is lost. This is not convenient for implementations.

  • Reported: XTCE 1.1 — Thu, 23 Mar 2017 17:20 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to define a local type for positive and non-negative integers

    To support a number of other changes and this issue, add two new types to the XTCE schema:

    <simpleType name="NonNegativeLongType">
    <annotation>
    <documentation>XTCE-specific replacement for xs:nonNegativeInteger which more cleanly maps to native data types.</documentation>
    </annotation>
    <restriction base="long">
    <minInclusive value="0"/>
    </restriction>
    </simpleType>

    <simpleType name="PositiveLongType">
    <annotation>
    <documentation>XTCE-specific replacement for xs:positiveInteger which more cleanly maps to native data types.</documentation>
    </annotation>
    <restriction base="long">
    <minInclusive value="1"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Use of raw value for calibrator context selection

  • Key: XTCE12-395
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    Should be able to select between calibrators by referencing raw value.

    Current ContextCalibrator mechanism doesn't really solve the problem. Access to raw value requires a parameter instance ref with useCalibratedValue=false. Implementing this approach requires a separate parameter type for each parameter that switches based on raw value. It also creates a somewhat circular relationship in the sense that the behavior of the parameter type (calibrator) depends on the parameter instance.

  • Reported: XTCE 1.1 — Mon, 5 Dec 2016 22:37 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-60

    Propose to accept that the resolution in MathOperationCalibratorType for XTCE12-60 also indirectly fixes this issue.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Fix annotation issues throughout schema

  • Key: XTCE12-27
  • Legacy Issue Number: 19398
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Address all annotation issues. Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This is too vague to address in this form, but it is being addressed

    The annotations do have issues and they are being addressed during specific issue resolutions. Propose to close this in favor of an audit for misses at the final stages of the XTCE 1.2 RTF.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

element ParameterInstanceRefOperand in the MathOperationType

  • Key: XTCE12-60
  • Legacy Issue Number: 17422
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept the recommendation for @useCalibratedValue and annotation improvements

    Still working from the Ballot 7 updated draft.

    The issue recommendation is reasonable. The following is an updated version of the MathOperationType complexType.

    The changes are exclusively in the annotations for the internal element content and the addition of the @useCalibratedValue attribute on the ThisParameterOperand element. The default is backwards compatible with XTCE 1.1 intent. Replace the existing definition of MathOperationType with:

    <complexType name="MathOperationType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Postfix (aka Reverse Polish Notation (RPN)) notation is used to describe mathmatical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="ValueOperand" type="double">
    <annotation>
    <documentation xml:lang="en">The element is used to represent a constant numeric value in the math operation.</documentation>
    </annotation>
    </element>
    <element name="ThisParameterOperand">
    <annotation>
    <documentation xml:lang="en">This element is a shortcut to represent the current parameter for which this math operation applies. It is shorter than using the ParameterInstanceRefOperatand, which can also specify this current parameter, but in a longer form syntax.</documentation>
    </annotation>
    <complexType>
    <attribute name="useCalibratedValue" type="boolean" default="true"/>
    </complexType>
    </element>
    <element name="ParameterInstanceRefOperand" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This element is used to reference the last received/assigned value of any Parameter in this math operation.</documentation>
    </annotation>
    </element>
    <element name="Operator" type="xtce:MathOperatorsType">
    <annotation>
    <documentation xml:lang="en">Binary operators: +, -, *, /, %, ^ operate on the top two values in the stack, leaving the result on the top of the stack. Unary operators: 1/x, x!, e^x, ln, log, and trigonometric operators operate on the top member of the stack also leaving the result on the top of the stack. 'ln' is a natural log where 'log' is a base 10 logarithm. Trigonometric operators use degrees. 'swap' swaps the top two members of the stack.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

The XTCE element MetaCommand has a child element called VerifierSet

  • Key: XTCE12-61
  • Legacy Issue Number: 17421
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to update previous fix

    The type inheritance issue was addressed in a previous resolution of types, but the annotation for VerifierSetType is still not clear, and the ExecutionVerifier element is missing the maxOccurs="unbounded".

    Change the documentation of the VerifierSetType complexType from:
    <documentation xml:lang="en">A Command Verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with difference states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple ‘complete’ verifiers. ‘Complete’ verifiers are added to the Base MetaCommand ‘Complete’ verifier list. All others will overide a verifier defined in a Base MetaCommand. </documentation>
    to:
    <documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with difference states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple ‘complete’ and 'execution' verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the 'complete' and 'execution' verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>

    Replace the element definition within VerifierSetType:
    <element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0"/>
    with:
    <element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Adding structure to Parameters

  • Key: XTCE12-67
  • Legacy Issue Number: 16721
  • Status: closed  
  • Source: Google ( Christopher Zonca)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Tue, 22 Nov 2011 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This issue resolved in conjunction with XTCE12-416

    The resolution of XTCE-416 proposed and approved in XTCE-418 provides a way to create the grouping of parameters requested. Since the resolution and approval have already occurred, I could not propose Duplicate/Merged as a resolution, so Closed/No change.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

IndirectParameterEntry should have segment varient?

  • Key: XTCE12-80
  • Legacy Issue Number: 14511
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Need a more compelling use case and application to spend time on IndirectParameterEntry

    Propose to close this without change in XTCE 1.2 because there does not yet appear to be a compelling need for a change here. There seems to be little use case for these Indirect element entries anyway.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Explain interaction of dynamic value and segments, array lastEntryForThisArray

  • Key: XTCE12-106
  • Legacy Issue Number: 14482
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged to proposal for XTCE12-107

    The root cause of this issue is that array definitions in XTCE 1.1 are broken. The repairs are part of the resolution for XTCE12-107. Merging this issue with that one to share resolutions.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Generalize array type, add attribute for ROW or COL order

  • Key: XTCE12-107
  • Legacy Issue Number: 14481
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to fix array definitions

    The first thing to do is to change the Array Parameter and Argument Type complexType elements in the schema. Here we are applying a maximum possible size to the array definitions. This allows implementations to reserve memory to store the parameter/argument data.

    Replace the ArrayParameterType definition with this new definition:

    <complexType name="ArrayParameterType">
    <annotation>
    <documentation>Describe an array parameter type. The size and number of dimensions are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayDataTypeType"/>
    </complexContent>
    </complexType>

    Replace the ArrayArgumentType definition with the following definition:

    <complexType name="ArrayArgumentType">
    <annotation>
    <documentation>Describe an array argument type. The size and number of dimension are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayDataTypeType"/>
    </complexContent>
    </complexType>

    Only minor adjustments in the Parameter and the Argument Array Entry inside of containers. This removes the @lastEntryForArrayInstance attribute and makes the DimensionList optional. When the DimensionList is not used, then the full size of the array is present.

    Change the ArrayParameterRefEntryType complexType to:

    <complexType name="ArrayParameterRefEntryType">
    <annotation>
    <documentation>Describe an entry that is an array parameter. Specify the dimension sizes if you are subsetting the array (the number of dimensions shall match the number defined in the parameter’s type definition), otherwise the ones in the ParameterType are assumed. See SequenceEntryType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:SequenceEntryType">
    <sequence minOccurs="0">
    <annotation>
    <documentation>Only used for subsetting an array. The array's maximum dimension sizes are set in the type. When a DimensionList is not used, the array is the full size provided in the type.</documentation>
    </annotation>
    <element name="DimensionList" type="xtce:DimensionListType">
    <annotation>
    <documentation>The dimension here if used for subsetting must be less than the ones in the type. It's not a subset if its the same size.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    Add the ArrayArgumentRefEntryType complexType:

    <complexType name="ArrayArgumentRefEntryType">
    <annotation>
    <documentation>Describe an entry that is an array argument. Specify the dimension sizes (the number of dimensions shall match the number defined in the parameter’s type definition). Valid constructions should have all indexes contiguously defined. See SequenceEntryType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ArrayParameterRefEntryType"/>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

StringDataType UTF-8/CharacterWidth Issue

  • Key: XTCE12-110
  • Legacy Issue Number: 14478
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Improve the ability to specify String Data Encoding

    Replace the simpleType StringEncodingType definition with the following definition containing a more comprehensive, annotated list of string encodings.

    <simpleType name="StringEncodingType">
    <annotation>
    <documentation xml:lang="en">Defines string encodings. US-ASCII (7-bit), ISO-8859-1 (8-bit Extended ASCII), Windows-1252 (8-bit Extended ASCII), UTF-8 (Unicode), UTF-16 (Unicode with Byte Order Mark), UTF-16LE (Unicode Little Endian), UTF-16BE (Unicode Big Endian). See StringDataEncodingType.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="US-ASCII"/>
    <enumeration value="ISO-8859-1"/>
    <enumeration value="Windows-1252"/>
    <enumeration value="UTF-8"/>
    <enumeration value="UTF-16">
    <annotation>
    <documentation xml:lang="en">With UTF-16, encoded bits must be prepended with a Byte Order Mark. This mark indicates whether the data is encoded in big or little endian.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="UTF-16LE">
    <annotation>
    <documentation xml:lang="en">With UTF-16LE, encoded bits will always be represented as little endian. Bits are not prepended with a Byte Order Mark.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="UTF-16BE">
    <annotation>
    <documentation xml:lang="en">With UTF-16BE, encoded bits will always be represented as big endian. Bits are not prepended with a Byte Order Mark.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="UTF-32">
    <annotation>
    <documentation xml:lang="en">With UTF-32, encoded bits must be prepended with a Byte Order Mark. This mark indicates whether the data is encoded in big or little endian.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="UTF-32LE">
    <annotation>
    <documentation xml:lang="en">With UTF-32LE, encoded bits will always be represented as little endian. Bits are not prepended with a Byte Order Mark.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="UTF-32BE">
    <annotation>
    <documentation xml:lang="en">With UTF-32BE, encoded bits will always be represented as big endian. Bits are not prepended with a Byte Order Mark.</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>

    Next, StringDataEncodingType is updated to allow for more flexible definition of string sizes by adding a Variable element as a replacement for SizeInBits, used in XTCE 1.1. The SizeInBits for XTCE 1.1 is now reserved for static length strings parameters.

    from

    <complexType name="StringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For common encodings of string data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="SizeInBits" type="xtce:SizeInBitsType"/>
    </sequence>
    <attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8"/>
    </extension>
    </complexContent>
    </complexType>

    to

    <complexType name="StringDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe common encodings of string data: UTF-8 and UTF-16. See StringDataType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <choice>
    <element name="SizeInBits" type="xtce:SizeInBitsType">
    <annotation>
    <documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
    </annotation>
    </element>
    <element name="Variable" type="xtce:VariableStringType">
    <annotation>
    <documentation xml:lang="en">A variable length string may change lengths between samples.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8"/>
    </extension>
    </complexContent>
    </complexType>

    With the change to the StringDataEncodingType, it is necessary to add a new type definition for the Variable element.

    <complexType name="VariableStringType">
    <annotation>
    <documentation xml:lang="en">Describe a variable string whose length may change between samples.</documentation>
    </annotation>
    <choice>
    <element name="LeadingSize" type="xtce:LeadingSizeType"/>
    <element name="DynamicValue" type="xtce:DynamicValueType"/>
    <element name="TerminationChar" type="hexBinary"/>
    <element name="DiscreteLookupList" type="xtce:DiscreteLookupListType"/>
    </choice>
    </complexType>

    To support this SizeInBits versus Variable distinction, a simplification is also made to SizeInBitsType since it is only used within StringDataEncoding. Replace the existing SizeInBitsType with this new one. Note that we have also removed the historic comment about Castor COTS and restored the default value.

    <complexType name="SizeInBitsType">
    <choice>
    <element name="Fixed">
    <complexType>
    <sequence>
    <element name="FixedValue" type="xtce:FixedIntegerValueType"/>
    </sequence>
    </complexType>
    </element>
    <element name="TerminationChar" type="hexBinary" default="00">
    <annotation>
    <documentation xml:lang="en">Like C strings, they are terminated with a special string, usually a null character.</documentation>
    </annotation>
    </element>
    <element name="LeadingSize" type="xtce:LeadingSizeType"/>
    </choice>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

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

  • Key: XTCE12-95
  • Legacy Issue Number: 14494
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept the recommendation for trigger container name reference type

    Propose to accept the issue recommendation.

    In the complexType InputOutputTriggerAlgorithmType, change the top-level documentation element:
    <documentation xml:lang="en">A set of labeled triggers is added to the SimpleInputOutputAlgorithmType</documentation>
    to:
    <documentation xml:lang="en">Input output algorithm is extended with a set of labeled triggers. See InputOutputAlgorithmType.</documentation>

    Change the attribute:
    <attribute name="triggerContainer" type="xtce:NameType" use="optional">
    to:
    <attribute name="triggerContainer" type="xtce:NameReferenceType" use="optional">

    Change the attribute priority from the integer type that translates to BigInteger:
    <attribute name="priority" type="integer" use="optional">
    to:
    <attribute name="priority" type="int" use="optional">

    Change the documentation for the priority from:
    <documentation xml:lang="en">Algorithm processing priority.</documentation>
    to:
    <documentation xml:lang="en">Algorithm processing priority. If more than one algorithm is triggered by the same container, the lowest priority algorithm should be calculated first.</documentation>

    For ease of review, the revised InputOutputTriggerAlgorithmType is:
    <complexType name="InputOutputTriggerAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Input output algorithm is extended with a set of labeled triggers. See InputOutputAlgorithmType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:InputOutputAlgorithmType">
    <sequence>
    <element name="TriggerSet" type="xtce:TriggerSetType" minOccurs="0"/>
    </sequence>
    <attribute name="triggerContainer" type="xtce:NameReferenceType" use="optional">
    <annotation>
    <documentation xml:lang="en">First telemetry container from which the output parameter should be calculated.</documentation>
    </annotation>
    </attribute>
    <attribute name="priority" type="int" use="optional">
    <annotation>
    <documentation xml:lang="en">Algorithm processing priority. If more than one algorithm is triggered by the same container, the lowest priority algorithm should be calculated first.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MathOperator needs to be cleaned up

  • Key: XTCE12-124
  • Legacy Issue Number: 14467
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Add annotation and additional operators

    Propose to update the type MathOperatorsType with documentation, add additional operators and correct ThisParameterOperandType.

    Replace the existing simpleType MathOperatorsType with the following new simpleType, containing documentation
    for all operators and the new operators: drop, dup, over.

    <simpleType name="MathOperatorsType">
    <annotation>
    <documentation>Mathematical operators used in the math operation. Behavior of each operator on the stack is described using notation (before – after), where "before" represents the stack before execution of the operator and "after" represent the stack after execution.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="+">
    <annotation>
    <documentation>addition (x1 x2 – x1+x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="-">
    <annotation>
    <documentation>subtraction (x1 x2 – x1-x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="*">
    <annotation>
    <documentation>multiplication (x1 x2 – x1*x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="/">
    <annotation>
    <documentation>division (x1 x2 – x1/x2) An undefined condition exists if x2 is zero</documentation>
    </annotation>
    </enumeration>
    <enumeration value="%">
    <annotation>
    <documentation>unsigned mod (x1 x2 – x3) Divide x1 by x2, giving the remainder x3; an undefined condition exists if x2 is zero</documentation>
    </annotation>
    </enumeration>
    <enumeration value="^">
    <annotation>
    <documentation>power function (x1 x2 – x1**x2)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="y^x">
    <annotation>
    <documentation>reverse power function (x1 x2 – x2**x1)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="ln"/>
    <annotation>
    <documentation>natural (base e) logarithm (x – ln(x)) An undefined condition exists if x is less than or equal to zero</documentation>
    </annotation>
    </enumeration>
    <enumeration value="log"/>
    <annotation>
    <documentation>base-10 logarithm (x-- log(x)) An undefined condition exists if x is less than or equal to zero</documentation>
    </annotation>
    </enumeration>
    <enumeration value="e^x">
    <annotation>
    <documentation>exponentiation (x – exp(x))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="1/x">
    <annotation>
    <documentation>inversion (x – 1/x) An undefined condition exists if x is zero</documentation>
    </annotation>
    </enumeration>
    <enumeration value="x!">
    <annotation>
    <documentation>factorial (x – x!) An undefined condition exists if x is less than zero</documentation>
    </annotation>
    </enumeration>
    <enumeration value="tan">
    <annotation>
    <documentation>tangent (x – tan(x)) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="cos">
    <annotation>
    <documentation>cosine (x – cos(x)) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="sin">
    <annotation>
    <documentation>sine (x – sin(x)) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="atan">
    <annotation>
    <documentation>arctangent (x – atan(x)) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="acos">
    <annotation>
    <documentation>arccosine (x – acos(x)) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="asin">
    <annotation>
    <documentation>arcsine (x – asin(x)) radians</documentation>
    </annotation>
    </enumeration>
    <enumeration value="tanh">
    <annotation>
    <documentation>hyperbolic tangent (x – tanh(x))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="cosh">
    <annotation>
    <documentation>hyperbolic cosine (x – cosh(x))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="sinh">
    <annotation>
    <documentation>hyperbolic sine (x – sinh(x))</documentation>
    </annotation>
    </enumeration>
    <enumeration value="atanh">
    <annotation>
    <documentation>hyperbolic arctangent (x – atanh(x)) An undefined condition exists if x is outside the range [-1.0,+1.0]</documentation>
    </annotation>
    </enumeration>
    <enumeration value="acosh">
    <annotation>
    <documentation>hyperbolic arccosine (x – acosh(x)) An undefined condition exists if n is less than one</documentation>
    </annotation>
    </enumeration>
    <enumeration value="asinh">
    <annotation>
    <documentation>hyperbolic arcsine (x – asinh(x)) </documentation>
    </annotation>
    </enumeration>
    <enumeration value="swap">
    <annotation>
    <documentation>swap the top two stack items (x1 x2 – x2 x1)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="drop">
    <annotation>
    <documentation>Remove top item from the stack (x – )</documentation>
    </annotation>
    </enumeration>
    <enumeration value="dup">
    <annotation>
    <documentation>Duplicate top item on the stack (x – x x)</documentation>
    </annotation>
    </enumeration>
    <enumeration value="over">
    <annotation>
    <documentation>Duplicate top item on the stack (x1 x2 – x1 x2 x1)</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>

    A mistake was introduced in a previous issue resolution. A new attribute was added to the ThisParameterOperand element in the complexType MathOperationType. The new attribute allows the specification of the calibrated or the uncalibrated value. This is nonsensical because the value of "this parameter" is not yet calibrated, which is why the calibrator is being evaluated.
    To resolve this, remove the extra attribute added and restore the type of the element to the more simple "string".
    <element name="ThisParameterOperand" type="string">
    <annotation>
    <documentation xml:lang="en">This element is a shortcut to represent the current parameter for which this math operation applies. It is shorter than using the ParameterInstanceRefOperand, which can also specify this current parameter, but in a longer form syntax.</documentation>
    </annotation>
    </element>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Autogenerator issue with schema type derivation

  • Key: XTCE12-113
  • Legacy Issue Number: 14475
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Appears to have been implemented with changes that added BaseDataType

    This appears to be overcome by the events that added the BaseDataType and also a BaseTimeDataType to cover the missing time types in the inheritance model. Suggest to close this now.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Unify metacommand/commandContainer and commandContainerSet/commandcontainer schema types

  • Key: XTCE12-111
  • Legacy Issue Number: 14474
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged to proposal for XTCE12-107

    The root cause of this issue is that array definitions in XTCE 1.1 are broken. The repairs are part of the resolution for XTCE12-107. Merging this issue with that one to share resolutions.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

FixedValueEntry@sizeInBits should be required

  • Key: XTCE12-88
  • Legacy Issue Number: 14500
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    FixedValueEntry@sizeInBits should be required

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept that FixedValueEntry ought to have @sizeInBits

    It does make sense that FixedValueEntry in the CommandContainer should have a mandatory @sizeInBits. It also can have an optional @name to identify the fixed field. Add documentation for the usage of the new and existing attributes of the FixedValueEntryType.

    Replace the existing definition of the complexType FixedValueEntryType with this updated definition.

    <complexType name="FixedValueEntryType">
    <complexContent>
    <extension base="xtce:SequenceEntryType">
    <attribute name="name" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">An optional name for the fixed/constant field in the sequence.</documentation>
    </annotation>
    </attribute>
    <attribute name="binaryValue" type="hexBinary" use="required">
    <annotation>
    <documentation xml:lang="en">The fixed/constant value that should be encoded into the sequence. This value provided should have sufficient bit length to accomodate the size in bits. If the value is larger, the most significant unnecessary bits are dropped. The value provided should be in network byte order for encoding.</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" use="required">
    <annotation>
    <documentation xml:lang="en">The number of bits that this fixed/constant value should occupy in the sequence.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ByteOrderList in XTCE 1.1 needs to be improved

  • Key: XTCE12-400
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    ByteOrderList is an element that describes the byte order of encoded packet info – mnemonics. Each mnemonic may have a different byte order. ByteOrderList is currently optional. The problems with it are:
    1) Not specifying it means the item is most significant byte first. But many adopters of XTCE fail to realize this initially at least producing many bad XTCE files.
    2) When specifying it, each "significance" is given a numerical value. The exact mechanism or meaning of this is not explained in the annotation. Results are a lack of commonality by XTCE file authors.
    3) There are 2 popular byte orders which cover many cases: "big" and "little" endian (or most/least significant byte first). Explicitly specifying these produces a lot of XML but a clearer XTCE file.
    Suggested fix: make the item required or provide an explicit default setting. This possibly means moving it to an attribute. Make the defaults the common settings, provide a bail out for the less common byte orders. Improve the annotation.

  • Reported: XTCE 1.1 — Fri, 16 Dec 2016 19:10 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Create "byteOrder" attribute

    Create "byteOrder" attribute similar to existing "bitOrder" attribute. Legal values for this attribute should include:

    • Common byte orderings (similar to BitOrderType)
      • "mostSignificantByteFirst" (default)
      • "leastSignificantByteFirst"
    • Arbitrary byte orderings (for backwards-compatibility with v1.1)
  • Updated: Tue, 10 Jul 2018 14:22 GMT

Remove whitespace in selector xpath attribute

  • Key: XTCE12-15
  • Legacy Issue Number: 19437
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XTCE schema contains several <key> elements to ensure unique "name" attributes across various namespaces. Namespaces searched are specified by the "xpath" attribute in the <selector> element.

    Several XTCE xpath attributes contain spaces to improve readability of the xpath expression. Although whitespace is allowed by paragraph 3.7 of the xpath specification, there is a bit of ambiguity since it's not in the formal BNF grammar. This means some schema processors (e.g., Eclipse modeling framework) may reject the xpath expression.

    Recommend removing the space around the union (|) operator in the xpath expressions.

  • Reported: XTCE 1.1 — Wed, 28 May 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Fix broken unique keys in XTCE 1.1

    Propose to replace the definition of the keys in the document. This is all except for the ArgumentName key, which does not show the problem described in this issue. The keys are defined in the SpaceSystemType, which is shown for contextual location below.

    <element name="SpaceSystem" type="xtce:SpaceSystemType" nillable="true">
    <annotation>
    <documentation>The top-level SpaceSystem is the root element for the set of metadata necessary to monitor and command a space device such as a satellite in mission operations. A SpaceSystem defines a namespace. Metadata areas include: packets/minor frames layout, telemetry, calibration, alarm, algorithms, streams and commands. A SpaceSystem may have child SpaceSystems, forming a SpaceSystem tree. See SpaceSystemType.</documentation>
    </annotation>
    <key name="parameterNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique parameter name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:ParameterSet/xtce:Parameter|xtce:CommandMetaData/xtce:ParameterSet/xtce:Parameter"/>
    <field xpath="@name"/>
    </key>
    <key name="parameterTypeNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique parameter type name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:ParameterTypeSet/|xtce:CommandMetaData/xtce:ParameterTypeSet/"/>
    <field xpath="@name"/>
    </key>
    <key name="metaCommandNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique metaCommand name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:MetaCommandSet/xtce:MetaCommand"/>
    <field xpath="@name"/>
    </key>
    <key name="algorithmNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique algorithm name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:AlgorithmSet/|xtce:CommandMetaData/xtce:AlgorithmSet/"/>
    <field xpath="@name"/>
    </key>
    <key name="streamNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique stream name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:StreamSet/|xtce:CommandMetaData/xtce:StreamSet/"/>
    <field xpath="@name"/>
    </key>
    <key name="serviceNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique service name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:ServiceSet/*"/>
    <field xpath="@name"/>
    </key>
    <key name="containerNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a container stream name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:ContainerSet/|xtce:CommandMetaData/xtce:ContainerSet/"/>
    <field xpath="@name"/>
    </key>
    <key name="messageNameKey">
    <selector xpath="xtce:TelemetryMetaData/xtce:MessageSet/*"/>
    <field xpath="@name"/>
    </key>
    <key name="eventNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique event name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:TelemetryMetaData/xtce:EventMessageSet/*"/>
    <field xpath="@name"/>
    </key>
    <key name="argumentTypeNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique argument type name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:ArgumentTypeSet/|xtce:CommandMetaData/xtce:ParameterTypeSet/"/>
    <field xpath="@name"/>
    </key>
    <key name="blockMetaCommandNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique BlockMetaCommand name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:MetaCommandSet/xtce:BlockMetaCommand"/>
    <field xpath="@name"/>
    </key>
    </element>

    This update also deprecates "ContainerKey2", which can be removed from the schema, which probably did not work anyway because of the missing namespace in the selector:

    <key name="ContainerKey2">
    <selector xpath="Container"/>
    <field xpath="Id"/>
    </key>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Improve CRCType Polynomial element

  • Key: XTCE12-12
  • Legacy Issue Number: 19436
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The annotation states that the coefficients of the CRC poly can only be 1 or 0, and the exponent can only be integers. However the schema types for these two attribute are double. Enforcing the annotation through changes to the syntax of its polynomial would be easy to accomplish. A new type for CRC polynomials would need to be created, and the attribute types changes to match the desired behavior.

  • Reported: XTCE 1.1 — Wed, 28 May 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Updated in previous issue resolution, not known which

    Create a CRCPolynomialType in the schema that only allows 0 or 1 for the coefficients and non-negative integers for the exponent and use it instead of the sequence of Polynomial elements.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Variable length strings need optional maximum length designator

  • Key: XTCE12-20
  • Legacy Issue Number: 19407
  • Status: closed  
  • Source: NASA ( James Rice)
  • Summary:

    way to specify the maximum length for variable length strings is missing. A related issue is for pascal-style strings is the bit/byte order of the preceding length is missing. (that makes this another issue but I am tired of adding issues to this thing!) Note: this is actually an old issue which somehow never made it into the issues list here that I can fine. I believe the original issue was relayed to me by EADS 5+ yrs ago. I thought they intended to put it in.

  • Reported: XTCE 1.1 — Mon, 5 May 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Working string issue in XTCE12-110

    Propose to address this issue along with the additional string data encoding concerns in XTCE12-110.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Repeat arguments

  • Key: XTCE12-22
  • Legacy Issue Number: 19404
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Repeat arguments group all other arguments (except more repeats) in a specified range - the range may allow the item to be optional, repeated a fixed number of time or repeated within the range. It's challenging to see how this is supported within current XTCE syntax. The suggestion is to add a repeat argument to the argument list in XTCE. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged to proposal for XTCE12-107

    The root cause of this issue is that array definitions in XTCE 1.1 are broken. The repairs are part of the resolution for XTCE12-107. Merging this issue with that one to share resolutions.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Fill argument

  • Key: XTCE12-23
  • Legacy Issue Number: 19403
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Fill arguments have a name and optional value, they are supplied by the system however. The closest match in XTCE is fixed value entry. However there's no way to associate a name with it or enforce the order in relation to other arguments, and if the container is not being specified this approach will not work either. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-88

    The resolution proposed for XTCE12-88 is XTCE12-387. That resolution also fixes this issue.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

At the Parameter element, initial values for Array or Aggregates may not be set.

  • Key: XTCE12-62
  • Legacy Issue Number: 17419
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to at least resolve this for aggregate members

    This resolution can build upon the refactoring already performed to improve the MemberList/Member element in the Aggregate type. Propose to add the missing @initialValue attribute.

    Update the new MemberType complexType to add this 1 attribute. Type shown below with attribute added:

    <complexType name="MemberType">
    <annotation>
    <documentation xml:lang="en">Describe a member field in an AggregateDataType. Each member has a name and a type reference to a data type for the aggregate member name. If this aggregate is a Parameter aggregate, then the typeRef is a parameter type reference. If this aggregate is an Argument aggregate, then the typeRef is an argument type reference. References to an array data type is currently not supported. Circular references are not allowed. See MemberListType. AggregateParameterType and AggregateArgumentType.</documentation>
    <appinfo>ensure no circular references</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="typeRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="initialValue" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">Used to set the initial calibrated values of Parameters. Will overwrite an initial value defined for the ParameterType. For integer types base 10 (decimal) form is assumed unless: if proceeded by a 0b or 0B, value is in base two (binary form, if proceeded by a 0o or 0O, values is in base 8 (octal) form, or if proceeded by a 0x or 0X, value is in base 16 (hex) form. Floating point types may be specified in normal (100.0) or scientific (1.0e2) form. Time types are specified using the ISO 8601 formats described for XTCE time data types. Initial values for string types, may include C language style (\n, \t, \",
    , etc.) escape sequences.</documentation>
    <appinfo>The value type must match the Parameter type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Member of an AggregateParameterType or AggregateArgumentType can't be an ArrayParameterType or ArrayArgumentType

  • Key: XTCE12-66
  • Legacy Issue Number: 17418
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-133

    The issue described here appears to be overcome by the resolution in XTCE12-133 where the DimensionList element was added to the Array Type declarations. This permits arrays to easily be used inside of structures, although fractions of arrays cannot be. This is probably not a critical issue.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Alarm count to enter alarm (minViolations), needs corresponding count to leave the alarm state

  • Key: XTCE12-59
  • Legacy Issue Number: 19368
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    In the current schema minViolation gives the count to go into alarm... But there is not attribute for leaving alarm. Note JPL is the original reporter.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-55

    This is a subset of issue XTCE12-55

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Change alarm

  • Key: XTCE12-51
  • Legacy Issue Number: 19373
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Change alarm define any change in value from a numeric, enum or string as in alarm. Float usage is often discouraged. XTCE has no specific syntax to support this. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-55

    This is a subset of the issue XTCE12-55.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Digital Alarms

  • Key: XTCE12-52
  • Legacy Issue Number: 19372
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Digital alarms are a mask (typically 16 bits) that have value and don't care bits. For example a mask might be defined as:

    X11X 10X0 0111 X111

    The X positions are don't care, but the 0,1 are values which if they appear in telemetry of interest put it into alarm.

    It isn't clear that this representable in XTCE.

    Original report is JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-54

    Merging this with the topic being evaluated in XTCE12-54. That issue appears to have a more complete description of this topic.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

remove extraneous keys or uniq

  • Key: XTCE12-74
  • Legacy Issue Number: 14514
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-15

    This is being addressed in another issue XTCE12-15. There is more than 1 duplicate of that issue.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ErroCorrectDetect -- Parity

  • Key: XTCE12-75
  • Legacy Issue Number: 14515
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-12

    Propose to correct this under the scope of XTCE12-12. There is a proposed update for CRC, Parity, XOR, and Checksum in ErrorDetectCorrect.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

In EnumerationAlarm, enumerationValue should called enumerationLabel

  • Key: XTCE12-71
  • Legacy Issue Number: 14518
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Correct ambiguous name of enumerationValue attribute

    Proposed to correct the name of the ambiguous attribute. This is not backwards compatible, but the conversion is a trivial enough code change and search/replace on existing documents as to not be arduous. In the complexType EnumerationAlarmLevelType replace the enumerationValue attribute with this definition:

    <attribute name="enumerationLabel" type="string" use="required"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

toString/NumberFormat needs default settings

  • Key: XTCE12-91
  • Legacy Issue Number: 14496
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept that default and annotations are a good idea

    Beginning work from the schema up to date with ballot 7 from Brad.

    The complexType NumberToStringType had a typo in that it did not close one of the <element> elements. This type below corrects that and also adds annotation for the NumberFormat element.

    <complexType name="NumberToStringType" abstract="true">
    <annotation>
    <documentation xml:lang="en">There are two ways numeric data can be changed to string data: using a Java style NumberFormat, or using an enumerated list. Enumerated lists can be assigned to a single value or a value range.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <choice>
    <choice maxOccurs="unbounded">
    <element name="ValueEnumeration" type="xtce:ValueEnumerationType">
    <annotation>
    <documentation xml:lang="en">A number or range assigned to a string.</documentation>
    </annotation>
    </element>
    <element name="RangeEnumeration" type="xtce:RangeEnumerationType"/>
    </choice>
    <element name="NumberFormat" type="xtce:NumberFormatType">
    <annotation>
    <documentation xml:lang="en">This element describes how a numeric value should be represented in engineering/calibrated form. The defaults reflect the most common form.</documentation>
    </annotation>
    </element>
    </choice>
    </extension>
    </complexContent>
    </complexType>

    The complexType NumberFormatType needed an update to assign the default values and also to add descriptive annotation to the attributes. The previous definition first:

    <complexType name="NumberFormatType">
    <attribute name="numberBase" type="xtce:RadixType" use="optional"/>
    <attribute name="minimumFractionDigits" type="nonNegativeInteger" use="optional"/>
    <attribute name="maximumFractionDigits" type="nonNegativeInteger" use="optional"/>
    <attribute name="minimumIntegerDigits" type="nonNegativeInteger" use="optional"/>
    <attribute name="maximumIntegerDigits" type="nonNegativeInteger" use="optional"/>
    <attribute name="negativeSuffix" type="string" use="optional"/>
    <attribute name="positiveSuffix" type="string" use="optional"/>
    <attribute name="negativePrefix" type="string" use="optional" default="-"/>
    <attribute name="positivePrefix" type="string" use="optional"/>
    <attribute name="showThousandsGrouping" type="boolean" use="optional" default="true"/>
    <attribute name="notation" type="xtce:FloatingPointNotationType" use="optional" default="normal"/>
    </complexType>

    Now, the updated definition of the type:

    <complexType name="NumberFormatType">
    <annotation>
    <documentation xml:lang="en">This type describes how a numeric value should be represented in engineering/calibrated form. The defaults reflect the most common form.</documentation>
    </annotation>
    <attribute name="numberBase" type="xtce:RadixType" use="optional" default="decimal">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to the radix. Default is base 10.</documentation>
    </annotation>
    </attribute>
    <attribute name="minimumFractionDigits" type="xtce:NonNegativeLongType" use="optional" default="0">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to the minimum number of fractional digits. The default is 0.</documentation>
    </annotation>
    </attribute>
    <attribute name="maximumFractionDigits" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to the maximum or upper bound of the number of digits. There is no default. No value specified should be interpreted as no upper bound such that all requires digits are used to fully characterize the value.</documentation>
    </annotation>
    </attribute>
    <attribute name="minimumIntegerDigits" type="xtce:NonNegativeLongType" use="optional" default="1">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to the minimum number of integer digits. The default is 1.</documentation>
    </annotation>
    </attribute>
    <attribute name="maximumIntegerDigits" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to the maximum or upper bound of the integer digits. There is no default. No value specified should be interpreted as no upper bound such that all requires digits are used to fully characterize the value.</documentation>
    </annotation>
    </attribute>
    <attribute name="negativeSuffix" type="string" use="optional" default="">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to negative values. This attribute specifies the character or characters that should be appended to the numeric value to indicate negative values. The default is none.</documentation>
    </annotation>
    </attribute>
    <attribute name="positiveSuffix" type="string" use="optional" default="">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to positive values. This attribute specifies the character or characters that should be appended to the numeric value to indicate positive values. The default is none. Zero is considered to be specific to the implementation/platform and is not implied here.</documentation>
    </annotation>
    </attribute>
    <attribute name="negativePrefix" type="string" use="optional" default="-">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to negative values. This attribute specifies the character or characters that should be prepended to the numeric value to indicate negative values. The default is a minus character "-".</documentation>
    </annotation>
    </attribute>
    <attribute name="positivePrefix" type="string" use="optional" default="">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to positive values. This attribute specifies the character or characters that should be prepended to the numeric value to indicate positive values. The default is none. Zero is considered to be specific to the implementation/platform and is not implied here.</documentation>
    </annotation>
    </attribute>
    <attribute name="showThousandsGrouping" type="boolean" use="optional" default="false">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to larger values. Groupings by thousand are specific to locale, so the schema only specifies whether they will be present and not which character separators are used. The default is false.</documentation>
    </annotation>
    </attribute>
    <attribute name="notation" type="xtce:FloatingPointNotationType" use="optional" default="normal">
    <annotation>
    <documentation xml:lang="en">Describes how the engineering/calibrated value of this number should be displayed with respect to notation. Engineering, scientific, or traditional decimal notation may be specified. The precise characters used is locale specific for the implementation/platform. The default is "normal" for the traditional notation.</documentation>
    </annotation>
    </attribute>
    </complexType>

    This proposal should add significant new clarity to this element. Not using this element in an XTCE document will imply the most common numeric formats that platforms tend to default to.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Move array sizing to Parameter and Argument from container area

  • Key: XTCE12-133
  • Legacy Issue Number: 14455
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Move array definition into the type definition

    Having the full array definition in the type definition instead of multiple sequence containers provides easier ground system interpretation. Schema change only.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

AlgorithmSet missing algorithms

  • Key: XTCE12-84
  • Legacy Issue Number: 14504
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This no longer appears to be an issue

    From reading the XTCE 1.1 and the latest XTCE 1.2 proposals, there does not seem to be a pressing need for an update and it may be obsolete (or perhaps a 1.0 legacy issue). Without additional clarity, propose to close this issue without change.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

FloatEncoding float formats -- MIL1750a, IEEE, bit size issues

  • Key: XTCE12-87
  • Legacy Issue Number: 14503
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

    DEC floating point encoding must also be accounted for.

    MILSTD-1750A 16 bit integer should probably have a comment that it is not float, rather it is just signMagnitude integer encoding.

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    UPDATED - Propose to resolve the missing mappings in FloatDataEncoding

    Significant discussion has been had regarding how to address the mappings in the FloatDataEncoding. The following proposal appears to represent a consensus that balances correctness with backwards compatibility.

    First it is necessary to replace two core types. These are the FloatEncodingSizeInBitsType and FloatEncodingType. The replacements for these two types with annotation to assist in selection are as follows:

    <simpleType name="FloatEncodingSizeInBitsType">
    <restriction base="unsignedShort">
    <!-- IEEE754_2008 "half" and MILSTD_1750A -->
    <enumeration value="16">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 16 bit encoding size is only valid in cases of IEEE754 and vendor specific MILSTD_1750A variation that is not a part of the standard. This is not meant to preclude use in the event that future floating point formats may also define this value.</documentation>
    </annotation>
    </enumeration>
    <!-- IEEE754_1985 and MILSTD_1750A and DEC and IBM and TI -->
    <enumeration value="32">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 32 bit encoding size is only valid in cases of IEEE754_1985, IEEE754, MILSTD_1750A, DEC, IBM, and TI. This is not meant to preclude use in the event that future floating point formats may also define this value. The IEEE754 enumeration and the IEEE754_1985 enumeration are allowed in this case and the interpretation is the same.</documentation>
    </annotation>
    </enumeration>
    <!-- TI -->
    <enumeration value="40">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 40 bit encoding size is only valid in the case of TI. This is not meant to preclude use in the event that future floating point formats may also define this value.</documentation>
    </annotation>
    </enumeration>
    <!-- MILSTD_1750A -->
    <enumeration value="48">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 48 bit encoding size is only valid in the case of MILSTD_1750A. This is not meant to preclude use in the event that future floating point formats may also define this value.</documentation>
    </annotation>
    </enumeration>
    <!-- IEEE754_1985 and DEC and IBM -->
    <enumeration value="64">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 64 bit encoding size is only valid in cases of IEEE754_1985, IEEE754, DEC, and IBM. This is not meant to preclude use in the event that future floating point formats may also define this value. The IEEE754 enumeration and the IEEE754_1985 enumeration are allowed in this case and the interpretation is the same.</documentation>
    </annotation>
    </enumeration>
    <!-- IEEE754_1985 -->
    <enumeration value="80">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 80 bit encoding size is only valid in the case of IEEE754_1985. This is not meant to preclude use in the event that future floating point formats may also define this value.</documentation>
    </annotation>
    </enumeration>
    <!-- IEEE754_1985 -->
    <enumeration value="128">
    <annotation>
    <documentation xml:lang="en">At the time of this writing, 128 bit encoding size is only valid in the case of IEEE754_1985 and IEEE754. This is not meant to preclude use in the event that future floating point formats may also define this value. The IEEE754 enumeration and the IEEE754_1985 enumeration are allowed in this case and the interpretation is the same.</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>
    <simpleType name="FloatEncodingType">
    <restriction base="string">
    <enumeration value="IEEE754_1985"/>
    <enumeration value="IEEE754"/>
    <enumeration value="MILSTD_1750A"/>
    <enumeration value="DEC"/>
    <enumeration value="IBM"/>
    <enumeration value="TI"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

toString/NumberFormat needs default settings

  • Key: XTCE12-7
  • Legacy Issue Number: 14497
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Provide default values for all attributes

    Provide default values for all attributes in NumberFormatType based on the default values from Java NumberFormat and DecimalFormat.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

XTCE12-11 fix for name references did not work correctly

  • Key: XTCE12-434
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The resolution for XTCE12-11 turned out to have an error. The Comments section outlines the error in that issue.

  • Reported: XTCE 1.1 — Thu, 23 Mar 2017 17:59 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to correct the mistake introduced in resolving XTCE12-11

    Replace the NameReferenceType simpleType in the schema with the following definition that includes a revised annotation and regular expression.

    <simpleType name="NameReferenceType">
    <annotation>
    <documentation>Describe a reference to a named item in an XTCE instance document. The named must be of schema type NameType. All name references use a Unix style file system name format where the SpaceSystem names form a path in the SpaceSystem tree. The following characters are reserved for the path: '/', ‘..’ and ‘.’ (multiple consecutive ‘/’s are treated as one). The path portion is similar to the directory path used in file system names and the path characters have similar meaning (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). There are three overall forms for name references: absolute path, relative path and just the name. The first two forms are called qualified name references; the last form is called an unqualified name reference. The unqualified form refers to an item in the SpaceSystem the reference is used in. The unqualified form refers to an item in the SpaceSystem the reference is used in. It is illegal for a name reference to point to no item (“a dangling name reference”).</documentation>
    </annotation>
    <restriction base="normalizedString">
    <pattern value="/?(([^./:\[\]]|\.|\.\.)/)*([^./:\[\]])+"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Member location within AggregateDataType

  • Key: XTCE12-416
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    AggregateDataType assumes each member immediately follows the previous member in the telemetry stream (no gaps). If there are unused bits in the stream, a dummy parameter must defined to account for the unused bits.

  • Reported: XTCE 1.0 — Tue, 10 Jan 2017 21:45 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Aggegrate data layout may be accomplished via existing container

    Use existing SequenceContainer capability (e.g., LocationInContainerInBits) to specify how members of an aggregate data type are received in a telemetry stream.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Provide specific type consequence level

  • Key: XTCE12-421
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XTCE v1.1 provided an anonymous type for the consequence level of a command. In proposed v1.2, consequence level type and AlarmLevels are merged into ConcernLevelsType. Besides being backwards-incompatible, this merges two different concepts.

  • Reported: XTCE 1.1 — Thu, 26 Jan 2017 18:13 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Define a consequence level type derived from ISO 14950

    Define a simple type (ConsequenceLevelType) for consequence level.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add ranges to enumeration list

  • Key: XTCE12-33
  • Legacy Issue Number: 19391
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add option to map a range of value to a label, instead of just one value as is current in XTCE. Reported by Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for a maxValue attribute in the ValueEnumerationType

    In order to accommodate a range of values in the Enumeration element of EnumerationList, a new @maxValue attribute is proposed and would have inclusive behavior.

    The schema is to be modified for the ValueEnumerationType as shown below with the additional attribute and the annotation:

    <complexType name="ValueEnumerationType">
    <annotation>
    <documentation>Describe a value and an associated string label, see EnumerationListType.</documentation>
    </annotation>
    <attribute name="value" type="integer" use="required"/>
    <attribute name="maxValue" type="integer">
    <annotation>
    <documentation>If max value is given, the label maps to a range where value is less than or equal to maxValue. The range is inclusive.</documentation>
    </annotation>
    </attribute>
    <attribute name="label" type="string" use="required"/>
    <attribute name="shortDescription" type="xtce:ShortDescriptionType"/>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Valid sizeInBits values for encoding="MILSTD_1750A"

  • Key: XTCE12-17
  • Legacy Issue Number: 19415
  • Status: closed  
  • Source: Jacobs Technology, Inc. ( Robert Goodwin)
  • Summary:

    The XTCE schema currently defines the following three legal values for sizeInBits in the FloatDataEncodingType complex type: 32, 64, 128. These legal values are correct if the encoding attribute is “IEEE754_1985”; but for encoding=”MILSTD_1750A”, the legal values should be 32 (single precision) and 48 (extended precision). Reference sections 4.1.5 and 4.1.6 of the MIL-STD-1750A specification (http://www.xgc.com/manuals/m1750-ada/m1750/book1.html). Need to add XTCE support for sizeInBits=48 when encoding=”MILSTD_1750A”.

  • Reported: XTCE 1.1 — Tue, 13 May 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-87

    Agree that this is an issue. It is being worked in XTCE12-87.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

StringAlarmList is required but it should be optional

  • Key: XTCE12-19
  • Legacy Issue Number: 19411
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    This is similar to issue 19370. StringParameterTypes can have several types of alarms but the StringAlarmList is required. Thus if you have a string alarm condition but nothing to go into the string alarm list, you have to make one up. For example if you are comparing the current string value to a past one in some manner, there is not necessarily a string alarm to go with it. The solution is to make the string alarm list optional.

  • Reported: XTCE 1.1 — Mon, 12 May 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for no StringAlarmList element in StringDataType

    Propose to resolve to allow for StringAlarmList to be optional in the StringDataType definition. This does have the side effect of allowing DefaultAlarm to have empty content, which is perhaps not so bad.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Database of single SpaceSystem cannot designate a parameter to be within multiple systems

  • Key: XTCE12-31
  • Legacy Issue Number: 19395
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Database of single SpaceSystem cannot designate a parameter to be within multiple systems. Add some way to categorize elements with @name.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-41

    Propose to address this issue with the resolution of XTCE12-41 as it appears to be the same request made at a different time.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add additional math operators to mathoperations

  • Key: XTCE12-32
  • Legacy Issue Number: 19394
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add additional operators to the math operations element. Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-124

    Resolution of XTCE12-124 will also resolve this issue.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add to or change way crc is specified

  • Key: XTCE12-24
  • Legacy Issue Number: 19400
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add to or change the way the crc is specified in the schema. Kratos/ISI

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-12

    Lets merge this topic/question/suggestion to XTCE12-12 where there is some additional detail about the issues with CRC.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add support for arbitary floating point

  • Key: XTCE12-26
  • Legacy Issue Number: 19399
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add support for arbitrary floating point formats within FLoatDataEncoding.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-87

    This topic is being addressed in XTCE12-87 where several other float issues are merged with.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Error detection algorithm does not support XOR

  • Key: XTCE12-28
  • Legacy Issue Number: 19397
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add XOR support in error detection algorithm. Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-12

    Propose to correct this under the scope of XTCE12-12. There is a proposed update for CRC, Parity, XOR, and Checksum in ErrorDetectCorrect.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add xinclude to support ximport

  • Key: XTCE12-10
  • Legacy Issue Number: 19632
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    To support xinclude, the following should added to the root schema element: <import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>

  • Reported: XTCE 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Add the import statement to the xsd

    This is to document the update to the xsd to add an import element for the xml.xsd namespace document from the W3C.

    For the top level <schema> element in the xsd, for the first child element should be an <import> element. Add the following:

    <import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>

    Also ensure that the definition of the SpaceSystem has the attribute @nillable="true".

    <element name="SpaceSystem" type="xtce:SpaceSystemType" nillable="true">

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add raw units to ParameterType

  • Key: XTCE12-45
  • Legacy Issue Number: 19379
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A specific syntactic element to capture raw units if it needed, possibly in addition to engineering units is not provided. There is a unit set in XTCE but was not intended to be used in this manner. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for specification of the unit form

    Propose to augment the UnitType for the Unit element to permit another optional attribute for the form of the units.

    Add a new simpleType to restrict the new attribute:

    <simpleType name="UnitFormType">
    <annotation>
    <documentation>Optionally specify if this information pertains to something other than the calibrated/engineering value.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="calibrated"/>
    <enumeration value="uncalibrated"/>
    <enumeration value="raw"/>
    </restriction>
    </simpleType>

    Update the annotation for the UnitType complexType, add annotation to the description attribute, and add the
    optional form attribute:
    <complexType name="UnitType" mixed="true">
    <annotation>
    <documentation>Describe the exponent, factor, form, and description for a unit. The unit itself is in element Unit in UnitSet. See UnitSetType. The attributes are optional because different programs use this element in different ways, depending on vendor support.</documentation>
    </annotation>
    <attribute name="power" type="double" use="optional" default="1"/>
    <attribute name="factor" type="string" use="optional" default="1"/>
    <attribute name="description" type="string" use="optional">
    <annotation>
    <documentation>A description of the unit, which may be for expanded human readability or for specification of the nature/property of the unit. For example, meters per second squared is of a nature/property of acceleration.</documentation>
    </annotation>
    </attribute>
    <attribute name="form" type="xtce:UnitFormType" use="optional" default="calibrated"/>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Expand telemetry parameter data source attribute

  • Key: XTCE12-49
  • Legacy Issue Number: 19378
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The XTCE options:
    telemetered, derived, constant, local

    The JPL options:
    flight, derived, bit_extract, simulation

    The suggestion is expand the list in XTCE to include "Segmented" or something of that nature to match the ParameterSegmentRefEntry.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to update the data source enumeration

    The nature of data source in Parameters is a feature that helps the ground system know what sorts of metadata attributes are needed to manage the parameters. It is not really meant to indicate anything about how the parameter is processed - that is covered in the parameter type.

    Some improvements are warranted and it seems like "ground" and "simulation" would be decent additions. The "simulation" is likely to be treated by vendors as a duplicate of "telemetered" for the purposes of the C2 software, although other domains may attach special behavior to that. "ground" is a case where the parameter is not provided by a spacecraft.

    The existing definition as it is currently based on other issues processed:

    <simpleType name="TelemetryDataSourceType">
    <annotation>
    <documentation xml:lang="en">A telemetered Parameter is one that will have values in telemetry. A derived Parameter is one that is calculated, usually by an Algorithm. A constant Parameter is one that is used as a constant in the system (e.g. a vehicle id). A local Parameter is one that is used purely on the ground (e.g. a ground command counter).</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="telemetered"/>
    <enumeration value="derived"/>
    <enumeration value="constant"/>
    <enumeration value="local"/>
    </restriction>
    </simpleType>

    Propose to update to (including an annotation update):

    <simpleType name="TelemetryDataSourceType">
    <annotation>
    <documentation xml:lang="en">A telemetered Parameter is one that will have values in telemetry. A derived Parameter is one that is calculated, usually be an Algorithm. A constant Parameter is one that is used as a constant in the system (e.g. a vehicle id). A local Parameter is one that is used purely by the software locally (e.g. a ground command counter). A ground Parameter is one that is generated by an asset which is not the spacecraft.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="telemetered"/>
    <enumeration value="derived"/>
    <enumeration value="constant"/>
    <enumeration value="local"/>
    <enumeration value="ground"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Need a ParameterProperty for "observability" or "change only threshold"

  • Key: XTCE12-68
  • Legacy Issue Number: 16722
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Wed, 23 Nov 2011 05:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for a @changeThreshold on the Float and Integer DataEncodingType(s)

    An additional of an optional attribute of @changeThreshold for the Float and Integer encoding elements is proposed.

    The schema would be modified using the information below. Only the updated attribute is shown in the context of the type name and complexContent to permit easy update. Other items in the complexContent may be addressed in other issues.

    <complexType name="FloatDataEncodingType">
    ...
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    ...
    </sequence>
    ...
    <attribute name="changeThreshold" type="double" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements. If the value is unspecified or zero, any change is significant.
    </documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    And in the case of the integer encoding:

    <complexType name="IntegerDataEncodingType">
    ...
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    ...
    </sequence>
    ...
    <attribute name="changeThreshold" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements, such as for an analog-to-digital converter that dithers in the least significant bit. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Enum Alarm List should be optional

  • Key: XTCE12-56
  • Legacy Issue Number: 19370
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The enum alarm list is required in the syntax. But other alarms types are available for enums, and it is possible that one may require one of them but not have need to define an explicit enum alarm list. The syntax prevents this from occurring. Perhaps the enum list element should be optional.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for no EnumerationAlarmList element in EnumeratedDataType

    Propose to resolve to allow for EnumerationAlarmList to be optional in the EnumeratedDataType definition. This does have the side effect of allowing DefaultAlarm to have empty content, which is perhaps not so bad.

    Add the @minOccurs = 0 attribute to the definition of the EnumerationAlarmList element in the complex type below. The parent elements are shown for the contextual location of the change.

    <complexType name="EnumerationAlarmType">
    <annotation>
    <documentation>Describe alarm conditions specific to the enumeration data type, extends the basic AlarmType with an EnumerationAlarmList. See EnumeratedParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="EnumerationAlarmList" type="xtce:EnumerationAlarmListType" minOccurs="0"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Bit extract feature needed in telemetry parameter

  • Key: XTCE12-58
  • Legacy Issue Number: 19367
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Specific syntax associating bits from one or more parent parameters to create a new parameter in the Parameter element is needed. Currently XTCE supports this concept at the container (ParameterSegmentEntryRef) level, and in theory by using an algorithm. However containers associated with some parameters may not always be defined in XTCE, and algorithmic descriptions are difficult to exchange. Note original reporter is JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Functionality exists in XTCE 1.2 proposed changes

    There are at least two ways to do this that have been proven.

    The first case is to use a derived TM parameter with bit operators (added in XTCE 1.2).

    The second case is to use a SequenceContainer to layout conventional TM parameters across the appropriate bits.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ContainerType issue

  • Key: XTCE12-6
  • Legacy Issue Number: 7659
  • Status: closed  
  • Source: Command and Control Technologies ( Greg Hupf)
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 24 Aug 2004 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    A SizeInBits element was added in XTCE 1.1

    This appears to have been corrected in XTCE 1.1 and this issue was brought over in error.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Time/Encoding@scale,@offset terminology vs DynamicValue/LinearAdjust

  • Key: XTCE12-86
  • Legacy Issue Number: 14502
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to make elements with slope intercept make more sense

    For the case of the LinearAdjustmentType complexType, remove the default values from the slope attribute. The LinearAdjustment element itself is optional, so when present, it should have some substantive content instead of being an empty element. In addition, the data type of the attributes should be double to prevent code generators from making specialty types, such as "BigDecimal".

    Existing definition:

    <complexType name="LinearAdjustmentType">
    <annotation>
    <documentation xml:lang="en">A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value</documentation>
    </annotation>
    <attribute name="slope" type="decimal" default="0"/>
    <attribute name="intercept" type="decimal" default="0"/>
    </complexType>

    Change attribute for @slope from:

    <attribute name="slope" type="decimal" default="0"/>

    To

    <attribute name="slope" type="double"/>

    Change attribute for @intercept from:

    <attribute name="intercept" type="decimal" default="0"/>

    To:

    <attribute name="intercept" type="double" default="0"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

*Container@abstract should have default of false

  • Key: XTCE12-96
  • Legacy Issue Number: 14491
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to set false default on container abstract

    Propose to update the schema by setting the default value on the @abstract attribute for SequenceContainer.

    The schema location for this attribute is at:

    <complexType name="SequenceContainerType">
    ...
    <complexContent>
    <extension base="xtce:ContainerType">
    <sequence>
    ...
    </sequence>
    <attribute name="abstract" type="boolean" default="false"/>
    ...
    </extension>
    </complexContent>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

size in bits of float encoding

  • Key: XTCE12-103
  • Legacy Issue Number: 14488
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-87

    Merging the resolution of this issue with XTCE12-87 that is being resolved with the proposal XTCE12-388.

  • Updated: Tue, 10 Jul 2018 14:22 GMT
  • Attachments:

Enumeration element could use an @shortDescription

  • Key: XTCE12-8
  • Legacy Issue Number: 18540
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

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

  • Reported: XTCE 1.1 — Sun, 10 Mar 2013 05:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for an optional @shortDescription in the Enumeration element

    Adding an optional @shortDescription to the Enumeration elements for parameter and argument types will satisfy some users. It is backwards compatible and can be easily ignored by uninterested parties. This attribute was inadvertently included in the proposed schema when the resolution for 12-136 was incorporated after ballot #6 was approved. If this resolution is not accepted the shortDescription attribute should be removed.

    The proposal is to add this attribute to the "ValueEnumerationType", which is applicable to both Parameter and Argument cases.

    <complexType name="ValueEnumerationType">
    <annotation>
    <documentation xml:lang="en">Contains a value and an associated string label. The value may be a range by specifying an upper maxValue range. If not a range, do not specify the maxValue.</documentation>
    </annotation>
    <attribute name="value" type="integer" use="required"/>
    <attribute name="maxValue" type="integer" use="optional"/>
    <attribute name="label" type="string" use="required"/>
    <attribute name="shortDescription" type="string" use="optional"/>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Change NameType regex from zero or more to one or more characters

  • Key: XTCE12-16
  • Legacy Issue Number: 19442
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    NameType's regex currently allows a name to be empty, and it should not allow this...

  • Reported: XTCE 1.1 — Mon, 2 Jun 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept the updated regular expression and broaden it

    This is a valid issue and the regular expression should be modified from:

    <simpleType name="NameType">
    <annotation>
    <documentation xml:lang="en">Used for "directory" style unique names. We need to preclude spaces, '.', '/', ':", "[" and "]". Only letters, digits, '_', ' ' and "-" are allowed </documentation>
    </annotation>
    <restriction base="string">
    <pattern value="[a-zA-Z0-9_\-]*"/>
    </restriction>
    </simpleType>

    To:

    <simpleType name="NameType">
    <annotation>
    <documentation>Defines a name where all characters are allowed except '.', '[', ']', ':', ' ', and '/'. See NameDescriptionType.</documentation>
    </annotation>
    <restriction base="normalizedString">
    <pattern value="[^./:\[\] ]+"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Range support in enumerated parameter type

  • Key: XTCE12-25
  • Legacy Issue Number: 19401
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add range support in enum list. Reported by ESA.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Allow for enumeration labels to have a range of values

    Enhance the ValueEnumerationType in the schema to allow a range and annotate the usage of the maxValue attribute, when present.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add regex to enforced syntax of NameReferences

  • Key: XTCE12-11
  • Legacy Issue Number: 19446
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    NameReferences which are "text pointers" in XTCE are currently an open string type, even though the form is "path-like" (e.g. sat/power/battery[0].voltage). There are a variety of forms of it and different types (regular namereferences and parameter instance refs). The syntax of these could be enforced with a regular expression. Below is an example that can used as basis for in the spec.

    <?xml version="1.0" encoding="UTF-8"?>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="test">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="path" maxOccurs="unbounded">
    <xs:simpleType>
    <xs:restriction base="xs:string">
    <xs:pattern value="/?(([a-zA-Z0-9_\-]|\.|\.\.)/)([a-zA-Z0-9_\-]([[0-9]])?)([\.][a-zA-Z0-9_\-]([[0-9]+])?)"/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    </xs:schema>

    — EXAMPLES

    <test xsi:noNamespaceSchemaLocation="path.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <path>foo</path>
    <path>foo[9].bar[0].baz[0]</path>
    <path>foo[0999]</path>
    <path>/foo/bar</path>
    <path>/foo/bar/baz</path>
    <path>/oo/bar/baz.bif</path>
    <path>/foo/bar[99].bif</path>
    <path>foo/bar[99].bif</path>
    <path>../././bar[99].bif</path>
    </test>

  • Reported: XTCE 1.1 — Wed, 4 Jun 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to accept the updated regular expression

    The issue description contains an updated regular expression that passes the tests needed. Propose to accept this restriction update in the NameReferenceType.

    Replace the restriction in NameReferenceType:
    <simpleType name="NameReferenceType">
    ...
    <restriction base="string"/>
    </simpleType>

    with the new restriction:
    <restriction base="string">
    <pattern value="/?(([a-zA-Z0-9_\-]|\.|\.\.)/)([a-zA-Z0-9_\-]([[0-9]])?)([\.][a-zA-Z0-9_\-]([[0-9]+])?)"/>
    </restriction>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Possible unused attribute in RepeatEntry

  • Key: XTCE12-13
  • Legacy Issue Number: 19443
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The RepeatEntry has a count element (required) and an offset element (optional). The offset element has four choices: offsetSizeInBits (attribute), FixedValue, DynamicValue, DiscreteLookupList (elements).

    The first item there seems a sore thumb... further you can easily say two conflicting things with it.

    The offsetSizeInBits is probably an vestige from an earlier version of the schema and can be removed.

  • Reported: XTCE 1.1 — Mon, 2 Jun 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to remove the redundant attribute

    OffsetType is only used in RepeatType. Eliminate OffsetType from the schema and define the Offset element in
    RepeatType as an IntegerValueType.

    Delete complexType OffsetType:
    <complexType name="OffsetType">
    <annotation>
    <documentation xml:lang="en">Indicates the distance between repeating entries (the last bit of one entry to the start bit of the next entry)</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:IntegerValueType">
    <attribute name="offsetSizeInBits" type="positiveInteger" default="1"/>
    </extension>
    </complexContent>
    </complexType>

    Replace element Offset in complexType RepeatType:
    <complexType name="RepeatType">
    ...
    <sequence>
    ...
    <element name="Offset" type="xtce:OffsetType" minOccurs="0"/>
    </sequence>
    </complexType>

    with the element:
    <element name="Offset" type="xtce:IntegerValueType" minOccurs="0"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

SplineCalibrator order attribute too restrictive

  • Key: XTCE12-57
  • Legacy Issue Number: 18537
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Fri, 8 Mar 2013 05:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update the data type for the @order in Spline Calibrators

    Proposed is to change the numeric type of the @order in the SplineCalibrator element. The 1.1 definition for this attribute is:

    <element name="SplineCalibrator">
    <annotation>
    <documentation xml:lang="en">A calibration type where a segmented line in a raw vs calibrated plane is described using a set of points. Raw values are converted to calibrated values by finding a position on the line corresponding to the raw value. The algorithm triggers on the input parameter.</documentation>
    </annotation>
    <complexType>
    <sequence>
    <element name="SplinePoint" type="xtce:SplinePointType" minOccurs="2" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="order" type="positiveInteger" default="1"/>
    <attribute name="extrapolate" type="boolean" default="false"/>
    </complexType>
    </element>

    The change would update the following:

    <attribute name="order" type="xtce:nonNegativeLongType" default="1"/>

    Also add the possibility for the SplinePoint element to override the @order on the SplineCalibrator. This should be specified on the first point in a pair if desired for the pair itself to be treated as a different @order than the SplineCalibrator overall. This assures backwards compatibility and simplifies the most common use case. Here is the update SplinePointType with the new attribute.

    <complexType name="SplinePointType">
    <annotation>
    <documentation xml:lang="en">a spline is a set of points from which a curve may be drawn to interpolate raw to calibrated values</documentation>
    </annotation>
    <attribute name="order" type="xtce:nonNegativeLongType" use="optional">
    <attribute name="raw" type="double" use="required"/>
    <attribute name="calibrated" type="double" use="required"/>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Condition has two elements with the same name, causes problems for some autogenerators

  • Key: XTCE12-81
  • Legacy Issue Number: 14508
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This no longer appears to be an issue

    There are three Condition elements and each has the same type specfication, although they are located in different places. Not sure the problem this causes. For now, propose to close without change for backwards compatibility.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

exponent attribute in Term element in PolynomialCalibrator should be non-negative integer

  • Key: XTCE12-77
  • Legacy Issue Number: 14516
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Accept that polynomial exponents are restricted to integer values

    Change data type of exponent attribute in TermType from double to NonNegativeLongType.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Package Identification: MessageKeys or Inheritance

  • Key: XTCE12-3
  • Legacy Issue Number: 8057
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

  • Reported: XTCE 1.0b1 — Fri, 31 Dec 2004 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

    This appears to have been addressed in XTCE 1.1. The issue probably came over with the database transition incorrectly.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

initialValue attribute only exists for a ParameterType or ArgumentType

  • Key: XTCE12-5
  • Legacy Issue Number: 7981
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

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

  • Reported: XTCE 1.0b1 — Wed, 15 Dec 2004 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

    This issue appears to have been addressed per the request of the submitter during XTCE 1.1 development and as such is not in scope for XTCE 1.2. This probably is here because of the issues database being brought forward.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

CommandContainer under the MetaCommand

  • Key: XTCE12-4
  • Legacy Issue Number: 7979
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

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

  • Reported: XTCE 1.0b1 — Wed, 15 Dec 2004 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

    It appears that this issue was corrected in XTCE 1.1 and is probably here because of a database transition issue. Propose to close without change in the context of XTCE 1.2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add explanatory annotation that MetaCommand/CommandContainer is semantically similar to a Java Private Inner Class

  • Key: XTCE12-104
  • Legacy Issue Number: 14483
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Not a well posed annotation

    This does not appear to be appropriate because Java is not the only implementation language or methodology. Private inner classes exist in multiple languages, but that isn't even relevant so much for people who use things like DOM. I suggest this is not a well posed thing to say in an annotation - at least as suggested. For now, propose to close without change.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add name attribute to context alarms or calibrators

  • Key: XTCE12-108
  • Legacy Issue Number: 14480
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Accept that @name could be optional in Alarms

    It appears that calibrators already got an update on another issue. Propose to update the AlarmType type to extend the "OptionalNameDescriptionType" with the existing AlarmType elements so that it inherits the optional @name and optional @shortDescription.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Key bugs

  • Key: XTCE12-109
  • Legacy Issue Number: 14479
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-15

    Agree to update these issues, but being performed under issue XTCE12-15.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Move ValidRangeAppliesToCalibrated Attribute

  • Key: XTCE12-112
  • Legacy Issue Number: 14477
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Accept that @validRangeAppliesToCalibrated is misplaced

    The attribute @validRangeAppliesToCalibrated only makes sense where there is a ValidRange element and this element is currently only defined for IntegerDataType and FloatDataType. Accept the proposal to relocate this attribute to the element for which it pertains.

    This takes changes to first remove the attribute from the NumericDataType type definition. The attribute line shown below is to be deleted:

    <complexType name="NumericDataType">
    ...
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </complexType>

    Then this attribute needs to be added to the types IntegerDataType and FloatDataType. These are shown below. Some content removed in favor of ellipses for clarity.

    <complexType name="FloatDataType">
    ...
    <complexContent>
    <extension base="xtce:NumericDataType">
    <sequence>
    <element name="ValidRange" minOccurs="0">
    ...
    <complexType>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    ...
    </extension>
    </complexContent>
    </complexType>

    <complexType name="IntegerDataType">
    ...
    <complexContent>
    <extension base="xtce:NumericDataType">
    <sequence>
    <element name="ValidRange" minOccurs="0">
    ...
    <complexType>
    <complexContent>
    <extension base="xtce:IntegerRangeType">
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </extension>
    </complexContent>
    </complexType>
    </element>
    </sequence>
    ...
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MessageSet has unneeded attribute

  • Key: XTCE12-94
  • Legacy Issue Number: 14493
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Make name & description of MessageSet optional and consistent with other types

    Make MessageSetType an extension of OptionalNameDescriptionType so that it still allows a name and a description of a MessageSet and is consistent with other types, but the name and description are not required. Move the existing annotation in the originally proposed MessageSetType back into TelemetryMetaDataType where it is more easily accessible.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DefaultSignicance element can have no content at all

  • Key: XTCE12-97
  • Legacy Issue Number: 14492
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to require @consequenceLevel in Significance elements

    It appears that a Significance element doesn't have any actionable meaning without at least @consequenceLevel. As a result, propose to make this attribute required in the schema.

    <complexType name="SignificanceType">
    <annotation>
    <documentation>Describe a reason (significance) of potential consequence of a MetaCommand for this or another space system. See ConcernLevelsType.</documentation>
    </annotation>
    <attribute name="spaceSystemAtRisk" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">If none is supplied, then the current SpaceSystem is assumed to be the one at risk by the issuance of this command</documentation>
    </annotation>
    </attribute>
    <attribute name="reasonForWarning" type="string"/>
    <attribute name="consequenceLevel" type="xtce:ConcernLevelsType" use="required" default="normal"/>
    </complexType>

    The use="required" default="normal" for the attribute consequenceLevel is the addition to this type.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

TimeAssociation schema type is incorrect

  • Key: XTCE12-118
  • Legacy Issue Number: 14463
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Change time offset to a more usable type

    The offset in TimeAssociationType is specified as an XML date, which would only allow whole day offsets. The typical offset is in seconds or fractions of a second. The offset will be flexibly defined with a default units of seconds. This affects the schema only.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

PercentComplete in Verifiers needs clean up

  • Key: XTCE12-121
  • Legacy Issue Number: 14470
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Revised proposal to fix PercentComplete Verifiers data type

    Modify the schema to create a PercentCompleteType that defines the characteristics of completion 0.-100., using a double precision floating point to retain the greatest compatibility in existing code with the DecimalValueType.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Remove old comments

  • Key: XTCE12-99
  • Legacy Issue Number: 14490
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Accept to remove editor metadata comments

    From the very top of the schema document, there exist metadata elements for CASTOR and XMLSpy. These should be removed from the schema. Note that users of XMLSpy can turn off this comment injection from the preferences/options menu.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

SplinePoint attribute order should be ignored (typo)

  • Key: XTCE12-100
  • Legacy Issue Number: 14487
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merged with resolution of 12-57

    This issue will be addressed during resolution of XTCE12-57.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

relative path in the parameterRef

  • Key: XTCE12-101
  • Legacy Issue Number: 14486
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    This appears to be an issue against a CCSDS document

    The XTCE specification does not include this chapter name or an example with the supplied text. This issue may have erroneously gone over to the OMG based on CCSDS document. Perhaps the magenta book?

  • Updated: Tue, 10 Jul 2018 14:22 GMT

packet identification

  • Key: XTCE12-102
  • Legacy Issue Number: 14485
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    This appears to be an issue against a CCSDS document

    The XTCE specification does not contain a chapter of this name. Perhaps this is an issue that erroneously got over to the OMG and is against a CCSDS document, such as the magenta book?

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Use of the include conditions

  • Key: XTCE12-105
  • Legacy Issue Number: 14484
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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?

  • Reported: XTCE 1.1 — Tue, 6 Oct 2009 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    This appears to be an issue against a CCSDS document

    This issue is not for the XTCE specification. It is a question for the CCSDS documentation. As such, it is out of scope for the OMG.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add APID table list

  • Key: XTCE12-37
  • Legacy Issue Number: 19387
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add an apid table list to XTCE so that packets defined in containers can be easily associated with their apid.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    This is a specific user community implementation request

    The CCSDS APID is described here in a form that is specific to a user community implementation. XTCE is general to the industry. There are good examples/templates and also the GovSat implementation/specification to cover the usage of XTCE in the context that is of interest to this user community. Suggest to close this as Out of Scope for XTCE in preference to this other information that is available.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add named width spacer to Container entry list

  • Key: XTCE12-42
  • Legacy Issue Number: 19383
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    named width spacer entry is an alternative way to do addressing as provided by the location in container element in XTCE. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-43

    See resolution in duplicate issue XTCE12-43

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add argument and fixed value entries to CommandContainerSet/CommandContainer

  • Key: XTCE12-21
  • Legacy Issue Number: 19402
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The CommandContainerSet/CommandContainer is missing arguments related entries which make it impossible to describes some ESA packet definitions.

    Reported by ESA.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    It is possible to specify ESA packets

    Arguments are local to MetaCommands and this is the root of the issue as to why they are not specified in the CommandContainerSet. There was a thought early on when implementing ECSS PUS where it was believed that this was needed. This is not the case and ECSS PUS can be specified without CommandContainerSet usage. Propose to close this.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

AlarmRanges cannot be defined based on raw values

  • Key: XTCE12-30
  • Legacy Issue Number: 19396
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Add raw value support in alarm ranges.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Values provided in XTCE documents usually normalize to calibrated/EU

    For operator readability, values in almost all locations specified in XTCE documents are in calibrated/engineering form. Existing database conversion tools commonly upconvert raw values where needed and this has not appeared to be an insurmountable hurdle.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add title to parameter

  • Key: XTCE12-44
  • Legacy Issue Number: 19380
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A specific syntactic item for a title associated with telemetry parameters is not available in XTCE. Reported by JPL

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Options are available in the current XTCE implementation

    The recommended path forward for programs is to map their internal schema to the XTCE schema considering that both short and long descriptions are already available. It is unusual to need a third description and in this case it might be more of an Alias than a description. We recommend using Alias with a @nameSpace of TITLE for capturing this if it cannot be mapped to short or long description. Additional possibilities exist and the committee can answer questions for that if posed in a more specific way.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

EnumeratedParameterType does not support multiple context alarms

  • Key: XTCE12-69
  • Legacy Issue Number: 15874
  • Status: closed  
  • Source: Google ( Christopher Zonca)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Mon, 29 Nov 2010 05:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Fix missing multiplicity on ContextAlarm in Enumerationed Type

    Add the multiplicity attribute to the schema for the element definition of the ContextAlarm.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

RelativeTimeType nomenclature conflicts with RelativeTimeParameterType

  • Key: XTCE12-79
  • Legacy Issue Number: 14510
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Propose to close this in favor of refactoring in other issues

    It appears that this confusion is somewhat reduced by the refactoring done to the type sets in another issue and there is also a RelativeTimeDataType to help alleviate. Propose to close this one without specific action.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

EnumeratedParameterType does not support multiple context alarms

  • Key: XTCE12-70
  • Legacy Issue Number: 15858
  • Status: closed  
  • Source: Google ( Christopher Zonca)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Mon, 29 Nov 2010 05:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    This is duplicated from XTCE12-69

    Propose to close this with no change as a duplicate of XTCE12-69.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

CommandContainer issue

  • Key: XTCE12-2
  • Legacy Issue Number: 7980
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

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

  • Reported: XTCE 1.0b1 — Wed, 15 Dec 2004 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Agree with the description

    It is correct that the CommandContainerSet has "CommandContainer" elements that are simply SequenceContainers in nature. It cannot have Arguments because arguments are local to a MetaCommand. They are of somewhat limited value because they can only contain parameters, but they can be used as base containers in many MetaCommands, to provide parameter entries for "system generated fields", such as header items for the command that would not be part of the operator driven set of Arguments to provide. The author of the comment was able to determine the utility of the CommandContainerSet from the existing specification and schema. Since we agree with the author of the question, we close without change.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

*Type/@initialValue need clarifications

  • Key: XTCE12-90
  • Legacy Issue Number: 14499
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    This is a legacy issue during XTCE 1.0 modifications for XTCE 1.1

    This issue was already resolved in XTCE 1.1 and may be present here because of issue database transition.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add ability to compare counters in IncludeCondition

  • Key: XTCE12-132
  • Legacy Issue Number: 14452
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Alternative valid representations are possible

    Custom algorithms are supported, and the requirement for this counter-based sampling is rare. Super-commutation and super-sampling are supported and item counts can be included in the container structure.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Create RangeEnumeration Type

  • Key: XTCE12-136
  • Legacy Issue Number: 14451
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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)

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Add optional attribute for range specification

    An optional attribute will be added to the ValueEnumerationType to allow using it as a range specification.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Clear Up Calibrated/Uncalibrated Values in Schema

  • Key: XTCE12-139
  • Legacy Issue Number: 14450
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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
  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Add Clarifying Annotation

    This will be clarified by annotating the associated elements in the schema.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Change UnitSet to simple String; change name

  • Key: XTCE12-115
  • Legacy Issue Number: 14472
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Propose not to change UnitSet contents

    We have made UnitSet an optional element in another issue. This change does not seem to add enough value to introduce a non-backwards compatible update that is largely cosmetic.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ContextAlarm not set to Inf Elements in EnumerationType

  • Key: XTCE12-130
  • Legacy Issue Number: 14457
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Correct typo in 1.1

    This was a typo that should have allowed an unbounded list of elements. Change only affects the schema.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Fix ArgumentTypes child element or attributes that use the term Parameter, to Argument

  • Key: XTCE12-135
  • Legacy Issue Number: 14453
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Eliminate type reference to Parameter-based type

    Current inheritance tree has Parameters and Arguments sharing base data types and attributes. The only reference to Parameter found in the base data types was the DimensionListType. Remove reference to Parameter in DimensionListType. Schema change only.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Change all elements to top level schema types

  • Key: XTCE12-35
  • Legacy Issue Number: 19389
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    By making all the elements top level schema types, the class mapping is cleaner.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Promote all Elements to Top Level Schema Types

    Promote the anonymous element types embedded in the schema to named top level types. This change does not affect the validity of existing XTCE 1.1 documents and aids software development through easier code generation from the schema using many available tools.

    New Top Level Type From Anonymous Type in Element
    ServiceSetType SpaceSystemType.ServiceSet
    ArgumentAssignmentListType MetaCommandType.BaseMetaCommand.ArgumentAssignmentList
    MetaCommandStepType CommandMetaDataType.MetaCommandSet.BlockMetaCommand.MetaCommandStepList.MetaCommandStep
    MetaCommandStepListType CommandMetaDataType.MetaCommandSet.BlockMetaCommand.MetaCommandStepList
    BlockMetaCommandType CommandMetaDataType.MetaCommandSet.BlockMetaCommand
    MessageType TelemetryMetaDataType.MessageSet.Message

    MessageSetType|TelemetryMetaDataType.MessageSet|

    RateInStreamSetType ContainerType.RateInStreamSet
    MessageRefSetType ServiceType.MessageRefSet
    ContainerRefSetType ServiceType.ContainerRefSet
    DimensionListType ArrayParameterRefEntryType.DimensionList
    PhysicalAddressSetType ParameterPropertiesType.PhysicalAddressSet
    StringContextAlarmType ParameterTypeSetType.StringParameterType.ContextAlarmList.ContextAlarm
    StringContextAlarmListType ParameterTypeSetType.StringParameterType.ContextAlarmList
    StringParameterType ParameterTypeSetType.StringParameterType
    EnumerationContextAlarmListType ParameterTypeSetType.EnumeratedParameterType.ContextAlarmList
    NumericContextAlarmListType ParameterTypeSetType.IntegerParameterType.ContextAlarmList and ParameterTypeSetType.FloatParameterType.ContextAlarmList
    EnumeratedParameterType ParameterTypeSetType.EnumeratedParameterType
    IntegerParameterType ParameterTypeSetType.IntegerParameterType
    BinaryParameterType ParameterTypeSetType.BinaryParameterType
    FloatParameterType ParameterTypeSetType.FloatParameterType
    BooleanContextAlarmListType ParameterTypeSetType.BooleanParameterType.ContextAlarmList
    BooleanParameterType ParameterTypeSetType.BooleanParameterType
    TimeContextAlarmListType ParameterTypeSetType.RelativeTimeParameterType.ContextAlarmList
    AggregateParameterType ParameterTypeSetType.AggregateParameterType
    ArrayParameterType ParameterTypeSetType.ArrayParameterType

    AbsoluteTimeParameterType|ParameterTypeSetType.AbsoluteTimeParameterType|

    RelativeTimeParameterType ParameterTypeSetType.RelativeTimeParameterType
    ValidIntegerRangeSetType ArgumentTypeSetType.IntegerArgumentType.ValidRangeSet
    StringArgumentType ArgumentTypeSetType.StringArgumentType
    BinaryArgumentType ArgumentTypeSetType.BinaryArgumentType
    EnumeratedArgumentType ArgumentTypeSetType.EnumeratedArgumentType
    IntegerArgumentType ArgumentTypeSetType.IntegerArgumentType
    ValidFloatRangeSetType ArgumentTypeSetType.FloatArgumentType.ValidRangeSet
    FloatArgumentType ArgumentTypeSetType.FloatArgumentType
    BooleanArgumentType ArgumentTypeSetType.BooleanArgumentType
    AbsoluteTimeArgumentType ArgumentTypeSetType.AbsoluteTimeArgumentType
    RelativeTimeArgumentType ArgumentTypeSetType.RelativeTimeArgumentType
    ArrayArgumentType ArgumentTypeSetType.ArrayArgumentType
    AggregateArgumentTypeArgumentTypeSetType.AggregateArgumentType
    ArgumentAssignmentType MetaCommandType.BaseMetaCommand.ArgumentAssignmentList.ArgumentAssignment
    ArgumentValueAssignmentType CommandMetaDataType.MetaCommandSet.BlockMetaCommand.MetaCommandStepList.ArgumentList.Argument
    ArgumentValueAssignmentListType CommandMetaDataType.MetaCommandSet.BlockMetaCommand.MetaCommandStepList.ArgumentList
    BaseMetaCommandType MetaCommandType.BaseMetaCommand
    MetaCommandSetType CommandMetaDataType.MetaCommandSet
    ArgumentType MetaCommandType.ArgumentList.Argument
    ArgumentListType MetaCommandType.ArgumentList
    TransmissionConstraintListType MetaCommandType.TransmissionConstraintList
    ContextSignificanceType MetaCommandType.ContextSignificanceList.ContextSignificance
    ContextSignificanceListType MetaCommandType.ContextSignificanceList
    InterlockType
    MetaCommandType.Interlock ExecutionVerifierType
    MetaCommandType.VerifierSet.ExecutionVerifier CompleteVerifierType
    MetaCommandType.VerifierSet.CompleteVerifier
    FailedVerifierType MetaCommandType.VerifierSet.FailedVerifier
    VerifierSetType MetaCommandType.VerifierSet
    ParameterToSetType MetaCommandType.ParameterToSetList.ParameterToSet
    ParameterToSetListType MetaCommandType.ParameterToSetList
    ParameterToSuspendAlarmsOnType MetaCommandType.ParametersToSuspendAlarmsOnSet.ParameterToSuspendAlarmsOn
    ParametersToSuspendAlarmsOnSetType MetaCommandType.ParametersToSuspendAlarmsOnSet
    ArgumentRefEntryType CommandContainerEntryListType.ArgumentRefEntry
    FixedValueEntryType CommandContainerEntryListType.FixedValueEntry
    ExternalAlgorithmType SimpleAlgorithmType.ExternalAlgorithmSet.ExternalAlgorithm
    ExternalAlgorithmSetType SimpleAlgorithmType.ExternalAlgorithmSet
    ConstantType InputAlgorithmType.InputSet.Constant
    InputSetType InputAlgorithmType.InputSet
    InputParameterInstanceRefType InputAlgorithmType.InputSet.ParameterInstanceRef
    OutputParameterRefType InputOutputAlgorithmType.OutputSet.OutputParameterRef
    OutputSetType InputOutputAlgorithmType.OutputSet
    SplineCalibratorType CalibratorType.SplineCalibrator
    PolynomialCalibratorType CalibratorType.PolynomialCalibrator
    MathOperationCalibratorType CalibratorType.MathOperationCalibrator
    OnParameterUpdateTriggerType TriggerSetType.OnParameterUpdateTrigger
    OnContainerUpdateTriggerType TriggerSetType.OnContainerUpdateTrigger
    OnPeriodicRateTriggerType TriggerSetType.OnPeriodicRateTrigger
    ParameterValueChangeType CommandVerifierType.ParameterValueChange
    CheckWindowType CommandVerifierType.CheckWindow
    CheckWindowAlgorithmsType CommandVerifierType.CheckWindowAlgorithms
    SyncPatternType FixedFrameStreamType.SyncStrategy.SyncPattern
    AutoInvertType SyncStrategyType.AutoInvert
    MemberType AggregateDataType.MemberList.Member
    MemberListType AggregateDataType.MemberList
    UnitSetType BaseDataType.UnitSet
    EncodingType BaseTimeDataType.Encoding
    EnumerationListType EnumeratedDataType.EnumerationList
    ContextCalibratorListType IntegerDataEncodingType.ContextCalibratorList
    StringSizeInBitsType StringDataEncodingType.SizeInBits
    AliasType AliasSetType.Alias
    ByteType ByteOrderType.Byte
    AncillaryDataType DescriptionType.AncillaryDataSet.AncillaryData
    AncillaryDataSetType DescriptionType.AncillaryDataSet
    ParityType ErrorDetectCorrectType.Parity
    CRCType ErrorDetectCorrectType.CRC
    AuthorSetType HeaderType.AuthorSet
    NoteSetType HeaderType.NoteSet
    HistorySetType HeaderType.HistorySet
    DynamicValueType DecimalValueType.DynamicValue and IntegerValueType.DynamicValue
    DiscreteLookupListType IntegerValueType.DiscreteLookupList
    ComparisonListType MatchCriteriaType.ComparisonList and CommandVerifierType.ComparisonList
    NumberFormatType NumberToStringType.NumberFormat
    TermType PolynomialType.Term
    OffsetType RepeatType.Offset
    EnumerationAlarmLevelType EnumerationAlarmType.EnumerationAlarmList.EnumerationAlarm
    StringAlarmLevelType StringAlarmType.StringAlarmList.StringAlarm
    RestrictionCriteriaType SequenceContainerType.BaseContainer.RestrictionCriteria and CommandContainerType.BaseContainer.RestrictionCriteria
    BinaryContextAlarmListType ParameterTypeSetType.BinaryParameterType.ContextAlarmList
    BaseContainerType SequenceContainerType.BaseContainer and CommandContainerType.BaseContainer
    BooleanContextAlarmType ParameterTypeSetType.BooleanParameterType.ContextAlarmList.ContextAlarm
    DimensionType ArrayParameterRefEntryType.DimensionList.Dimension
    LinearAdjustmentType IntegerValueType.DynamicValue.LinearAdjustment and DecimalValueType.DynamicValue.LinearAdjustment
    EnumerationContextAlarmType ParameterTypeSetType.EnumeratedParameterType.ContextAlarmList.ContextAlarm
    EnumerationAlarmListType EnumerationAlarmType.EnumerationAlarmList
    FixedFrameSyncStrategyType FixedFrameStreamType.SyncStrategy
    VariableFrameSyncStrategyType VariableFrameStreamType.SyncStrategy
    TriggeredMathOperationType MathAlgorithmType.MathOperation
    ToStringType NumericDataType.ToString
    ParameterType ParameterSetType.Parameter
    DerivationType ParameterToSetType.Derivation
    ChangeValueType CommandVerifierType.ParameterValueChange.Change
    LocationInContainerInBitsType SequenceEntryType.LocationInContainerInBits
    AlgorithmTextType SimpleAlgorithmType.AlgorithmText
    LeadingSizeType StringDataEncodingType.SizeInBits.LeadingSize
    StringAlarmListType StringAlarmType.StringAlarmList
    TimeAlarmRangesType TimeAlarmType.StaticAlarmRanges and TimeAlarmType.ChangesPerSecondAlarmRanges
    TransmissionConstraintType MetaCommandType.TransmissionConstraintList.TransmissionConstraint
    TransferredToRangeVerifierType MetaCommandType.VerifierSet.TransferredToRangeVerifier
    SentFromRangeVerifierType MetaCommandType.VerifierSet.SentFromRangeVerifier
    ReceivedVerifierType MetaCommandType.VerifierSet.ReceivedVerifier
    AcceptedVerifierType MetaCommandType.VerifierSet.AcceptedVerifier
    QueuedVerifierType MetaCommandType.VerifierSet.QueuedVerifier
    BinaryContextAlarmType ParameterTypeSetType.BinaryParameterType.ContextAlarmList.ContextAlarm
    DiscreteLookupType IntegerValueType.DiscreteLookupList.DiscreteLookup
    ChangeAlarmRangesType NumericAlarmType.ChangeAlarmRanges
    LongDescriptionType DescriptionType.LongDescription
    ShortDescriptionType DescriptionType.ShortDescription
    HistoryType HistorySetType.History
    NoteType NoteSetType.Note
    ContextMatchType ContextSignificanceType.ContextMatch, ContextCalibratorType.ContextMatch, BinaryContextAlarmType.ContextMatch, BooleanContextAlarmType.ContextMatch, EnumerationContextAlarmType.ContextMatch, StringContextAlarmType.ContextMatch, NumericContextAlarmType.ContextMatch, TimeContextAlarmType.ContextMatch
    FlagType VariableFrameStreamType.SyncStrategy.Flag
    BasisType RateInStreamType.basis
    TelemetryDataSourceType ParameterPropertiesType.dataSource
    PCMType PCMStreamType.pcmType
    BitOrderType DataEncodingType.bitOrder
    IntegerEncodingType IntegerDataEncodingType.encoding
    FloatEncodingType FloatDataEncodingType.encoding
    StringEncodingType StringDataEncodingType.encoding
    TAIType EpochType
    ValidationStatusType HeaderType.validationStatus
    TimeWindowIsRelativeToType CommandVerifierType.CheckWindow.timeWindowIsRelativeTo
    ParityFormType ErrorDetectCorrectType.Parity.type
    ReferencePointType ErrorDetectCorrectType.Parity.reference
    FloatingPointNotationType NumberToStringType.NumberFormat.notation
    ReferenceLocationType SequenceEntryType.LocationInContainerInBits.referenceLocation
    ChangeSpanType NumericAlarmType.ChangeAlarmRanges.changeType
    ChangeBasisType NumericAlarmType.ChangeAlarmRanges.changeBasis
    FlagBitType VariableFrameStreamType.SyncStrategy.Flag.flagBitType
    FloatSizeInBitsType FloatDataType.sizeInBits and FloatDataEncodingType.sizeInBits
    CharacterWidthType StringDataType.characterWidth
    AuthorType HeaderType.AuthorSet.Author
  • Updated: Tue, 10 Jul 2018 14:22 GMT
  • Attachments:

Fix spelling of one/twosCompliment in IntegerDataEncoding

  • Key: XTCE12-36
  • Legacy Issue Number: 19390
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    It should be complement, not compliment. Reported by Kratos/ISI.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Correct the spelling error

    Perform a global search and replace on the schema document to search for and replace "twosCompliment" in favor of "twosComplement".

    Perform a global search and replace on the schema document to search for and replace "onesCompliment" in favor of "onesComplement".

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MetaCommandSet is incorrectly set to required

  • Key: XTCE12-9
  • Legacy Issue Number: 19634
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The MetaCommandSet is incorrectly set to required and should be optional, like all the other "top-level" elements in XTCE.

  • Reported: XTCE 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Set the minimum on MetaCommandSet to 0 within CommandMetaData

    This is to capture the change to the minimum count for MetaCommandSet inside of CommandMetaData elements.

    The @minOccurs should be added and set to zero in the schema. For example:

    <element name="MetaCommandSet" minOccurs="0">

    No other element in the schema has @name equal to MetaCommandSet.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

AggregateParameterType or AggregateArgumentType Member attribute 'typeRef' is vague

  • Key: XTCE12-64
  • Legacy Issue Number: 17417
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update schema documentation for Aggregate Members

    Some additional annotation in the schema is warranted. Update the annotation element for MemberType(s).

    <complexType name="MemberType">
    <annotation>
    <documentation>Describe a member field in an AggregateDataType. Each member has a name and a type reference to a data type for the aggregate member name. If this aggregate is a Parameter aggregate, then the typeRef is a parameter type reference. If this aggregate is an Argument aggregate, then the typeRef is an argument type reference. References to an array data type is currently not supported. Circular references are not allowed. See MemberListType. AggregateParameterType and AggregateArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseDescriptionType">
    <attribute name="name" type="xtce:NameType" use="required"/>
    <attribute name="typeRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

  • Key: XTCE12-65
  • Legacy Issue Number: 17405
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    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

  • Reported: XTCE 1.1 — Tue, 5 Jun 2012 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    locationInContainerInBits clarification in annotation

    From:
    <element name="LocationInContainerInBits" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">If no LocationInContainer value is given, the entry is assumed to begin immediately after the previous entry.</documentation>
    </annotation>

    To:
    <element name="LocationInContainerInBits" type="xtce:LocationInContainerInBitsType" minOccurs="0">
    <annotation>
    <documentation>Addresses are relative to the container the entry is in. Zero is always the start of the container. If the container is an entry in another, the referring container's entry address is added to the one being referred to the compute addresses. For container inheritance, the root container starts at address zero.</documentation>
    </annotation>
    </element>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Message/ContainRef should read ContainerRef

  • Key: XTCE12-117
  • Legacy Issue Number: 14462
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Element name should match convention

    The ContainRef element in MessageType should be named ContainerRef to match other reference element names in the schema. This affects the schema only.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Put Alarms in Arguments; leaves Alarms in Command Parameters

  • Key: XTCE12-126
  • Legacy Issue Number: 14461
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Not essential to definition exchange

    Command arguments are typically associated with operator entry of a command request, or a scripted command request. XTCE Command argument definitions may include a valid range which would define for the ground system the invalid range to reject at command request time. This rejection is not the same as a valid alarm, and the action that the ground system takes when it receives an invalid argument value is system-dependent, but should result in the rejection of the command request.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Change UnitSet to optional

  • Key: XTCE12-123
  • Legacy Issue Number: 14471
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    make UnitSet optional

    UnitSet is required on all parameter types & argument types even when the item does not have a unit. The result is a lot of empty </UnitSet> tags in XTCE xml files. The proposal to fix this is to make it optional. This will suffice since units are important, people won't forget them (probably). And it is backwards compatible.

    From:

    <element name="UnitSet">

    To:

    <element name="UnitSet" type="xtce:UnitSetType" minOccurs="0"/>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Clean up Annotation Related to Verifiers

  • Key: XTCE12-125
  • Legacy Issue Number: 14469
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    change annotation to reflect intended meaning of syntax

    Change in schema annotation only.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Clarify ContainerRef check in Verification area

  • Key: XTCE12-122
  • Legacy Issue Number: 14468
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update annotation on ContainerRef is Command Verifier base type

    The annotation is not clear when using the element ContainerRef in the various types of Command Veriifier elements. The base xtce:CommandVerifierType contains the element and annotation that is shared amongst these.

    Update the annotation text on the definition of the element ContainerRef below. The parent elements are shown for finding this location in the context of the document.

    <complexType name="CommandVerifierType" abstract="true">
    <annotation>
    <documentation>Describe a command verifier to check that the command has been successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The CheckWindow is a time period where the verification must test true to pass. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <sequence>
    <choice>
    <element name="ComparisonList" type="xtce:ComparisonListType"/>
    <element name="ContainerRef" type="xtce:ContainerRefType">
    <annotation>
    <documentation xml:lang="en">When verification is a new instance the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet.</documentation>
    </annotation>
    </element>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ErrorDetectCorrect does not support Checksum

  • Key: XTCE12-127
  • Legacy Issue Number: 14459
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Extend ErrorDetectCorrectType to support checksum algorithms

    Define a new ChecksumType complexType after AlgorithmTextType in the schema. Add a Checksum element of ChecksumType to the ErrorDetectCorrectType

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Label Missing in IntegerType/RangeEnumeration area

  • Key: XTCE12-131
  • Legacy Issue Number: 14456
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    *Add RangeEnumerationType with a label attribute *

    Create a complex type, RangeEnumerationType and and a label attribute to associate the label with a range of data.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

attribute twosCompliment should be twosComplement

  • Key: XTCE12-89
  • Legacy Issue Number: 14501
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Duplicate of 12-36

    This is a report of the same typo as Issue 12-36

  • Updated: Tue, 10 Jul 2018 14:22 GMT

No short description or long description at the Member element of AggregateParameterType or AggregateArgumentType

  • Key: XTCE12-63
  • Legacy Issue Number: 17416
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Have Member element extend NameDescriptionType similar to Parameter and Argument

    It makes sense to have the Member element be more like it's brethren, the Parameter and Argument elements. By having it inherit from NameDescriptionType, it will solve this issue and make it more generically consistent with the others.

    Modify the xsd to reflect this new content for the MemberType complexType:

    <complexType name="MemberType">
    <annotation>
    <documentation>Describe a member field in an AggregateDataType. Each member has a name and a type reference to a data type for the aggregate member name. If this aggregate is a Parameter aggregate, then the typeRef is a parameter type reference. If this aggregate is an Argument aggregate, then the typeRef is an argument type reference. References to an array data type is currently not supported. Circular references are not allowed. See MemberListType. AggregateParameterType and AggregateArgumentType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="typeRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </complexContent>
    </complexType>

    Note that this takes into account the already worked update to the description/annotation of this type.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

OnBoard Software

  • Key: XTCE12-150
  • Legacy Issue Number: 9222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Should be considered as a future specification

    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.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

OnBoard Memory

  • Key: XTCE12-148
  • Legacy Issue Number: 9221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Should be considered as a future specification

    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.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

CalibratorType

  • Key: XTCE12-152
  • Legacy Issue Number: 9204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Specification allows custom calibration types

    The MathOperationCalibrator was included to cover conversions that are not a simple linear or polynomial conversion. Since only one known system supports the logarithmic conversion, it can use this element. SCOS 2000 converters could recognize the internal conversion from the sequence of ln() operators and use the internal conversion type rather than a custom derivation. Other systems that do not implement the logarithmic conversion will only be able to support it through a custom derivation. An XTCE example of the formula above with coefficients, -5, 1, .1, .01, .001, is shown below.
    <xtce:FloatParameterType name="LnConvertedType"
    shortDescription="Example of natural log conversion using RPN calibrator">
    <xtce:UnitSet /><xtce:IntegerDataEncoding sizeInBits="16">
    <xtce:DefaultCalibrator>
    <xtce:MathOperationCalibrator>
    <xtce:ThisParameterOperand/>
    <xtce:Operator>ln</xtce:Operator>
    <xtce:ValueOperand>4</xtce:ValueOperand>
    <xtce:Operator>y^x</xtce:Operator>
    <xtce:ValueOperand>.001</xtce:ValueOperand>
    <xtce:Operator>*</xtce:Operator>
    <xtce:ThisParameterOperand/>
    <xtce:Operator>ln</xtce:Operator>
    <xtce:ValueOperand>3</xtce:ValueOperand>
    <xtce:Operator>y^x</xtce:Operator>
    <xtce:ValueOperand>.01</xtce:ValueOperand>
    <xtce:Operator>*</xtce:Operator>
    <xtce:Operator>+</xtce:Operator>
    <xtce:ThisParameterOperand/>
    <xtce:Operator>ln</xtce:Operator>
    <xtce:ValueOperand>2</xtce:ValueOperand>
    <xtce:Operator>y^x</xtce:Operator>
    <xtce:ValueOperand>.1</xtce:ValueOperand>
    <xtce:Operator>*</xtce:Operator>
    <xtce:Operator>+</xtce:Operator>
    <xtce:ThisParameterOperand/>
    <xtce:Operator>ln</xtce:Operator>
    <xtce:ValueOperand>1.0</xtce:ValueOperand>
    <xtce:Operator>*</xtce:Operator>
    <xtce:Operator>+</xtce:Operator>
    <xtce:ValueOperand>-5.0</xtce:ValueOperand>
    <xtce:Operator>+</xtce:Operator>
    <xtce:Operator>1/x</xtce:Operator>
    </xtce:MathOperationCalibrator>
    </xtce:DefaultCalibrator></xtce:IntegerDataEncoding>
    </xtce:FloatParameterType>

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Section: 7

  • Key: XTCE12-151
  • Legacy Issue Number: 9083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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)

  • Reported: XTCE 1.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Future XTCE profile specifications and validation tools

    Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MM-001 What missions need

  • Key: XTCE12-155
  • Legacy Issue Number: 9073
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Future XTCE profile specifications and validation tools

    Some communities of use (US Government and CCSDS) are establishing more specific restrictions that will either be published as companion specifications in OMG or as standalone specifications within the community of use. The creation of a validation tool would be appropriate for the community of use to verify that a valid XTCE document meets the more stringent restrictions.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

HVM-004 Data Encoding definitions

  • Key: XTCE12-188
  • Legacy Issue Number: 9038
  • Status: closed  
  • Source: es ( Hans van der Meij)
  • Summary:

    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.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Add clarifying information in section 6.1.2.1.

    In section 6.1.2.1 in the next to last paragraph (paragraph before reference to Figure 4) add clarifying information.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MK-002 Type of element[MessageRef] is undefined

  • Key: XTCE12-153
  • Legacy Issue Number: 9072
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Version 1.1

    This issue appears to have been written against version 1.0. The deficiency was corrected by the version 1.1 RTF with the resolution of issue 10162.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MP-001 Terminology

  • Key: XTCE12-156
  • Legacy Issue Number: 9071
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Variation in terminology

    There is considerable variation in terminology and definitions, depending on the community of use. There are other efforts to assemble ontologies for space systems. Including one in this specification would be duplicative and not necessarily definitive.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

TH-001 Some Typos

  • Key: XTCE12-154
  • Legacy Issue Number: 9070
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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'.
  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in a previous revision.

    This issue appears to have been written against the adopted specification and was resolved in the finalization to publish version 1.0.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Should use type[FixedFrameSyncStrategyType] in type [FixedFrameStreamType]

  • Key: XTCE12-158
  • Legacy Issue Number: 9069
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in a previous revision.

    This issue appears to have been written against the adopted specification and was resolved in the finalization to publish version 1.0.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MK-005 Should use type[ContextCalibratorType] in …

  • Key: XTCE12-157
  • Legacy Issue Number: 9068
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in a previous revision.

    This issue appears to have been written against the adopted specification and was resolved in the finalization to publish version 1.0.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

V-003 Schema file identification

  • Key: XTCE12-160
  • Legacy Issue Number: 9067
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Version 1.1

    This issue appears to have been written against a draft prior to schema version 1.1. The version number appears in a documentation element near the beginning of the schema and should be updated with each new specification version.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-013 Parameter encoding information

  • Key: XTCE12-161
  • Legacy Issue Number: 9066
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merge with other parameter encoding issue

    Duplicate of parameter encoding issue already resolved.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MS-001 Missing page numbering

  • Key: XTCE12-159
  • Legacy Issue Number: 9065
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in a prior revision

    This issue appears to have been written against a draft prior to version 1.1. All pages of the specification document have proper numbering

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MS-003 Meaning not clear.

  • Key: XTCE12-162
  • Legacy Issue Number: 9064
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    This issue appears to have been written against a draft prior to version 1.1. The wording of the paragraph in version 1.1 is clearer.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

8 - Add activity field to Alarms to indicate what the alarm will trigger

  • Key: XTCE12-141
  • Legacy Issue Number: 10176
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

    Defer (further discussion needed)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Future replacement specification

    Linkage of operations procedures/activities to alarms was not in the original RFP requirements and was not addressed by any of the submissions, therefore this is an enhancement request that could be considered in a future RFP/RFC.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

5 - Align XTCE and CCSDS Navigation Schemas (types)

  • Key: XTCE12-144
  • Legacy Issue Number: 10173
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    5 - Align XTCE and CCSDS Navigation Schemas (types) (JPL-029)

    Defer (possible future work area)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Future replacement specification

    The CCSDS Navigation schema has progressed with their own element types. There is limited overlap between the two specifications, and a unification of element types would be an enhancement request to the XTCE specification. This enhancement could be considered in a future RFC/RFP.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

3 - Use UML Instance diagrams for XTCE document example

  • Key: XTCE12-142
  • Legacy Issue Number: 10171
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

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

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Future XTCE profile specifications and validation tools

    Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

- Add separate CalibratorSet to XTCE

  • Key: XTCE12-145
  • Legacy Issue Number: 10170
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

    Defer (breaks current XTCE model, complexity)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Not essential to information exchange

    Systems that use a table of calibrations/conversions referenced by individual parameters can generate that table from an XTCE document by reading and identifying duplicate calibrators when inserting them into the table. Requiring that structure in the XTCE schema is not essential to the information exchange.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

1 - Support ability to describe redundant or complimentary data

  • Key: XTCE12-147
  • Legacy Issue Number: 10169
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

    Defer (complexity)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Should be considered as a future specification

    General relationships between command and telemetry items falls more in the realm of ontologies, and is out of scope of the original XTCE RFP.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

CommandContainerType

  • Key: XTCE12-149
  • Legacy Issue Number: 9206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Specification allows fixed values in CommandContainers

    XTCE does support the required functionality of a fixed value, and combinations of containers can support the desired structure. 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.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-033 Line 6

  • Key: XTCE12-166
  • Legacy Issue Number: 9062
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-027 Line 3

  • Key: XTCE12-173
  • Legacy Issue Number: 9053
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-032 Line 3

  • Key: XTCE12-174
  • Legacy Issue Number: 9052
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-034 Line 10

  • Key: XTCE12-178
  • Legacy Issue Number: 9051
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-018 Line 10

  • Key: XTCE12-175
  • Legacy Issue Number: 9050
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-005 Figure

  • Key: XTCE12-182
  • Legacy Issue Number: 9044
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-026 Encoding area

  • Key: XTCE12-183
  • Legacy Issue Number: 9042
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-024 Line 6

  • Key: XTCE12-168
  • Legacy Issue Number: 9060
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-030 Line 5

  • Key: XTCE12-167
  • Legacy Issue Number: 9058
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-016 Line 4.

  • Key: XTCE12-169
  • Legacy Issue Number: 9057
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in a prior revision

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-020 Line 4

  • Key: XTCE12-171
  • Legacy Issue Number: 9056
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-008 Line 4

  • Key: XTCE12-170
  • Legacy Issue Number: 9055
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-029 Line 1

  • Key: XTCE12-177
  • Legacy Issue Number: 9048
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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"

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-011 Figure text.

  • Key: XTCE12-180
  • Legacy Issue Number: 9046
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Some sections/pages refer to the old (1.0) xsd version

  • Key: XTCE12-137
  • Legacy Issue Number: 12803
  • Status: closed  
  • Source: NLR ( Leo Timmermans)
  • Summary:

    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 ]

  • Reported: XTCE 1.1 — Wed, 3 Sep 2008 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Update schema name, namespace and references

    Schema name, namespace, and references will be made consistent with the current OMG policy.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

9 - Add filtering of value threshold to maintain telemetry at certain rates

  • Key: XTCE12-138
  • Legacy Issue Number: 10177
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

    Defer (additional discussion, future work area)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Add optional change filtering attribute to numeric parameters

    Exchange information for this functionality (change threshold) can be incorporated by adding an optional attribute to the IntegerDataEncodingType and FloatDataEncodingType without breaking existing export and import implementations.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

7 - Use UUIDs instead of current XTCE Referencing mechanism

  • Key: XTCE12-140
  • Legacy Issue Number: 10175
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

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

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Future replacement specification

    UUIDs may be a useful way to coordinate separate development of related XTCE documents. This was not one of the requirements in the original RFP, and was not addressed by any of the submissions, therefore this is an enhancement request that could be considered in a future RFP/RFC.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

6 - Add ToString to Boolean or remove Boolean in favor of Enumerated Types

  • Key: XTCE12-146
  • Legacy Issue Number: 10174
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

    Defer (no agreement on approach)

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Not essential to information exchange

    While there is overlap between the concepts, Boolean and enumerated types are both supported in most programming languages because of implied differences in meaning. For that reason, XTCE will continue to support Booleans as a separate data type. Booleans can be implemented as an enumerated type by ground systems, but for a round-trip exchange, the True/False enumerations would have to be recognized as an XTCE Boolean.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

4 - Separate XTCE Schema into constituent parts

  • Key: XTCE12-143
  • Legacy Issue Number: 10172
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

    Defer (possible future work area

  • Reported: XTCE 1.0 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Future replacement specification

    During the combination of the original submissions and finalization, the schema was separated into related sections. XML tool support was poor at the time for schemas with includes. While tool support has improved, splitting the specification at this time would break existing implementations and is considered an enhancement request for future RFPs/RFCs, but is out of scope for the XTCE 1.x specifications

  • Updated: Tue, 10 Jul 2018 14:22 GMT

repeat of arguments issue

  • Key: XTCE12-211
  • Legacy Issue Number: 8886
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0b1 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Closed; Out Of Scope — XTCE 1.2
  • Disposition Summary:

    Repeating arguments for memory loads

    Extension of the argument concept to cover repeating argument blocks is not in the scope of the original RFP. There is a workaround that utilizes aggregrate parameter types instead of arguments.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

XTCE issue: dimensionList in arrayParameterRef should be optional

  • Key: XTCE12-209
  • Legacy Issue Number: 8704
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0b1 — Tue, 26 Apr 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merge with 14455 resolution.

    A resolution of 14455 would conflict with a resolution for this issue, and 14455 is the preferred approach to array sizing.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-004 "Philosophy", line 2

  • Key: XTCE12-200
  • Legacy Issue Number: 9030
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in previous revision

    This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

"Parameter Processing" box

  • Key: XTCE12-195
  • Legacy Issue Number: 9029
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Typo corrected in previous revision

    See issue 10237 in RTF Report dtc/06-12-02 for disposition (typo corrected in previous revision)

  • Updated: Tue, 10 Jul 2018 14:22 GMT

"Foreword", line 2.

  • Key: XTCE12-198
  • Legacy Issue Number: 9028
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in previous revision

    This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

"Foreword", 2nd last line

  • Key: XTCE12-196
  • Legacy Issue Number: 9027
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in previous revision

    This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MK-007 Don't need element[ChangePerSecondAlarmConditions]

  • Key: XTCE12-187
  • Legacy Issue Number: 9040
  • Status: closed  
  • Source: jaxa.jp ( Makoto Kawai)
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MS-009 De-calibration of cmd parameters?

  • Key: XTCE12-189
  • Legacy Issue Number: 9039
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-021 Assembly / dissembly of streams

  • Key: XTCE12-186
  • Legacy Issue Number: 9037
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Examples developed by communities of use

    Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications or related tutorial documentation, since they will differ by community.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-017 Assembly / dissembly information.

  • Key: XTCE12-190
  • Legacy Issue Number: 9036
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Examples developed by communities of use

    Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications or related tutorial documentation, since they will differ by community.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MP-004 Logarithmic calibrations

  • Key: XTCE12-163
  • Legacy Issue Number: 9063
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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?)

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Merge with Calibrator Issue

    XTCE12-152 contains a better description of the missing calibration capabilities.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-009 Line 6

  • Key: XTCE12-165
  • Legacy Issue Number: 9061
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in a prior revision

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-028 ArgumentList

  • Key: XTCE12-191
  • Legacy Issue Number: 9035
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in previous revision

    This appears to have been an issue against the adopted specification draft. The schema annotation describes the purpose of the MetaCommand arguments.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MK-010 All ParameterType and ArgumentType should have alarm element

  • Key: XTCE12-192
  • Legacy Issue Number: 9034
  • Status: closed  
  • Source: jaxa.jp ( Makoto Kawai)
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Duplicate or Merged — XTCE 1.2
  • Disposition Summary:

    Duplicate of current and previously corrected issues

    See issues 14461 and 14466 for more specific alarm element issues. EnumeratedAlarmType already added during finalization.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MK-003 A mistake of type[ContainerSegmentRefEntryType]'s annotation

  • Key: XTCE12-194
  • Legacy Issue Number: 9032
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Does not add to clarity

    The annotation was reviewed and is correct in the existing schema. The suggested change does not add to the clarity.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-023 Line 3.

  • Key: XTCE12-172
  • Legacy Issue Number: 9054
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Revise Section 6.1.3

    Remove the erroneous reference to MessageSet in section 6.1.3. It is not a part of CommandMetaData.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-025 Encoding information

  • Key: XTCE12-184
  • Legacy Issue Number: 9043
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MP-007 Dynamic telemetry check types

  • Key: XTCE12-185
  • Legacy Issue Number: 9041
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Alternatives for Dynamic Alarm Checking

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-012 Line 5

  • Key: XTCE12-164
  • Legacy Issue Number: 9059
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in Revision 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-010 Line 1

  • Key: XTCE12-176
  • Legacy Issue Number: 9049
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

    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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MS-006 Footing of Figure 1 is missing.

  • Key: XTCE12-179
  • Legacy Issue Number: 9047
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

DC-015 Figure label.

  • Key: XTCE12-181
  • Legacy Issue Number: 9045
  • Status: closed  
  • Source: scisys ( Dave Campbell)
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in XTCE version 1.1

    No change dispositions from original poll 2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Expand features to include common industry encodings in StreamsSet

  • Key: XTCE12-38
  • Legacy Issue Number: 19386
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Added specific support for reed-solomon and turbo encoding, among others in the stream set. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Propose to defer this as out of scope in the XTCE 1.2 resolutions

    This seems somewhat of a significant issue for making a truly data driven model for applications. Unfortunately, there does not appear to have been any work done to make the StreamSet feature in XTCE solid. Propose to defer this to another RTF unless someone can come up with a proposal to comprehensively work this. Vote against if you can do it.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add switch entry to container entry list

  • Key: XTCE12-40
  • Legacy Issue Number: 19385
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A switch entry is similar to the switch/case statement provided in most programming languages, and would improve upon the include condition currently found in XTCE. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Agree in principle but perhaps not in scope of XTCE 1.2

    The IncludeCondition functions as designed in XTCE at present. We agree that this is an interesting an intriguing idea but would be a new series of code that implementations would need to support. Since the existing capability is not broken in this sense, it is preferable to defer this to a possible 2.0 type of specification.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add gap entry to container entry list

  • Key: XTCE12-43
  • Legacy Issue Number: 19384
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A gap entry is an addressing mechanism to move the address pointer relative or absolutely as specified in the gap entry. This is an alternate approach to XTCE's location in container element. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Good idea but not needed in current scope

    This is an interesting idea. The current method has shown to be implementable by several vendors, so there is not a defect. Adding this new requirement would impact vendor support/adoption time/effort for XTCE 1.2. Because this does not actually represent a defect, I propose to defer it to a "2.0" for re-consideration.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add variable to containers

  • Key: XTCE12-46
  • Legacy Issue Number: 19382
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Variables are local values created from bit/sub-bits specified in the entry list of container. They are similar to parameters but exist only within the scope of the container they are defined – they are of type integer. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Propose to defer this to a later XTCE RFP

    This an interesting idea that has merit.

    Currently, the requested functionality can be achieved with XTCE as designed, but the Parameters would not be local. Some segregated parameters in a "scratch" Space System can be used to stand in for this feature without trouble.

    At least 1 other project has done something like this when more than 1 interpretation of a series of bits in a container are needed and 1 of the interpretations is temporary for doing other comparisons/restrictions.

    It could be better, but is out of scope for XTCE 1.2 because it would be a significant design change. No block to existing programs in 1.2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Provide way to categorize all elements with @name into one or more groups

  • Key: XTCE12-41
  • Legacy Issue Number: 19381
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Outside of the SpaceSystem and systemName, a general mechanism for categorizing @name elements into one or groups is needed. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    The ability to create categories sufficiently exists

    Creating categories for organizing named items in the XTCE document exists in the schema and has been enhanced slightly in XTCE 1.2 by adding names to more areas.

    AncillaryData is already used by several programs to create arbitrary categories that are not needed for export to other tool chains. This is sufficient for this purpose.

    A previous addition to the schema to create new elements for this purpose was not accepted by ballot.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Xpath:

  • Key: XTCE12-205
  • Legacy Issue Number: 8927
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0b1 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    No Xpath for cross-references

    Requiring an Xpath definition for the cross-references would break existing XTCE exchange implementations and would not necessarily reduce the amount of code required to implement an export or import tool.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

command side unable to describe "packed commands"

  • Key: XTCE12-207
  • Legacy Issue Number: 8907
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Use nested command containers

    A metacommand container can contain nested containers, thus allowing more than one “command” in a single packet. XTCE does not specify the transfer protocol layer that might control packet splitting and reassembly onboard

  • Updated: Tue, 10 Jul 2018 14:22 GMT

XTCE issue - add shortDescription to EntryList entries

  • Key: XTCE12-212
  • Legacy Issue Number: 8703
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0b1 — Tue, 26 Apr 2005 04:00 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

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

    Add an optional shortDescription attribute to the SequenceEntryType. As an optional description, it will not affect the upward (1.1 to 1.2) interpretation of existing XTCE documents. The attribute can easily be stripped from a 1.2 document for processing by a 1.1 compatible tool. A 1.1 tool using schema-based parsing will ignore the optional field, when updated with the 1.2 schema.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

"Command Processing" box

  • Key: XTCE12-202
  • Legacy Issue Number: 9025
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Typo corrected in previous revision

    See issue 10237 in RTF Report dtc/06-12-02 for disposition (typo corrected in previous revision)

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Spec too complex?

  • Key: XTCE12-201
  • Legacy Issue Number: 8962
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Future model-based specifications

    There is substantial variation in the capabilities and features of existing ground and space systems. The increasing complexity of space-systems, as they transition to greater reliance on software, makes it difficult to reduce complexity and still span the variation in systems. Community of use-based limitations are emerging which simplify the application of XTCE, and these should result in new companion specifications. Eventually a new specification for software-based ground-space interfaces, based on other OMG software communication specifications, e.g. CORBA, DDS, IDL, will be required to satisfy more complex systems.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

USE CCSDS examples how to use the standard

  • Key: XTCE12-203
  • Legacy Issue Number: 8961
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Examples of use will be defined by the community

    Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

too much leeway how to use the standard

  • Key: XTCE12-206
  • Legacy Issue Number: 8960
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Limitations on exchange should be defined in separate profiles

    There is extreme variation in the capabilities and limitations of the various ground systems now in use. A conscious decision was made early in the finalization process not to create a definition language that is least common denominator, since that would be too restrictive for emerging implementations. Some communities of use (US Government and CCSDS) are establishing more specific restrictions that will either be published as companion specifications in OMG or as standalone specifications within the community of use.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Propose that XCTE ( at this point ) will be limited to exchange data

  • Key: XTCE12-204
  • Legacy Issue Number: 8959
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.0 — Fri, 5 Aug 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Within scope of existing specification

    This is the scope defined in the XTCE specification. Any expansions of that scope would have to be considered in a new RFP.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Contents"

  • Key: XTCE12-197
  • Legacy Issue Number: 9026
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in previous revision

    This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Type inheritance missing from Absolute and Relative time data types

  • Key: XTCE12-14
  • Legacy Issue Number: 19633
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Absolute and Relative time should have a "baseType" similar to the other scalar data types. This is probably an oversight.

  • Reported: XTCE 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Propose to defer this as out of scope in the XTCE 1.2 resolutions

    There appear to be some improvements to the time specifications in previous issue resolutions for 1.2. This is a structural "nice to have" in the data model, but does not prevent successful user implementations. Defer to a future version of XTCE.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add ArgumentTypeSet to MetaCommand

  • Key: XTCE12-48
  • Legacy Issue Number: 19377
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Allow for local argument types to be defined in MetaCommand, helps avoid collisions with arguments in other commands of the same name but different properties.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Defer to future XTCE revision

    This is an interesting idea, but it seems to not be worthwhile for the extra effort needed to make this happen by vendor implementations. The current method does work as-is. Argument types do not need to be named the same as the Arguments, so name collision is avoidable, even with sharing of base types.

    Perhaps this could be addressed in a model-based XTCE 2.0

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Elevate annotation specifying time string formats to an attributes

  • Key: XTCE12-47
  • Legacy Issue Number: 19376
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The annotation below would be better served as an optional attribute with the specified format as the default. From a telemetry stantpd this would be interpreted as optional display info, and from an argument standpt the user input string format. "Used to contain an absolute time. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. "

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Propose to defer this to another RTF or RFP

    This seems like a reasonable idea, but perhaps not critical in the context of XTCE 1.2. Time display formats are implementation, locale, and program specific. Not sure there is a real problem here, but I agree there is ambiguity.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Need support for mask alarm

  • Key: XTCE12-54
  • Legacy Issue Number: 19371
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A mask alarm applies to numerics and enums – although usage in floats is discouraged. It defines 16-states which map 1 to 1 with values (say 1-16), it's a 16-bit mask – each bit is either a care or don't care. If set to 1, it's a care bit. If the value associated with that bit appears, it is in alarm. If the mask bit is set to 0, it's a don't care bit – and the value associated with it will not trip an alarm. When used with enums it's almost like an enum alarm list,except the states can go "past" the range of values given in the enum list itself. For example, suppose an enum had the values of OPEN=1, SHUT=2. The mask could be 0xfffffffc - as one and two are allowed and valid. And any other value would be in alarm. Because there's only two enum values and each of these is green but any other value is read, it is hard to completely simulate this alarm with the enum alarm list. It's possible to use a condition perhaps in this one example but the current syntax requires the enum alarm list. Further transferring this information through to another party will be hard in that case. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Mask alarm capability exists but is not as clean as it could be

    It is possible to define mask alarms with the latest improvements in the XTCE 1.2 proposal. As a result, we propose to defer this request. It is deferred instead of closed because there is a possibility that this could be implemented. It would impact other comparisons, so for now it is chosen not to do that.

    For the case of enumerations, the implementer should be aware that any undefined enumeration is an alarm of sorts. This is implementation specific. The capability now to define ranges in enumerations also help define explicit out-of-bounds alarms if needed.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Should RestrictionCriteria should be assignment not operators for Commanding?

  • Key: XTCE12-82
  • Legacy Issue Number: 14506
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Propose to defect this to a later XTCE RFP

    The issue appears to make sense. Changing this would be a significant update to the structure of the schema and might break existing usage not foreseen. Propose to defer this topic to an RFP update as opposed to the tighter scoped RTF for 1.2.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

AO-006 Additional examples (2)

  • Key: XTCE12-193
  • Legacy Issue Number: 9033
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Incorporate in community of use specifications or non-normative venues

    Good examples would enhance the specification, but at this point the examples are emerging from the communities of use (CCSDS, US Government) and are probably most appropriate to be included in those specifications, since they will differ by community.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

MK-001 A mistake of attribute[messageRef]'s annotation

  • Key: XTCE12-199
  • Legacy Issue Number: 9031
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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"

  • Reported: XTCE 1.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.2
  • Disposition Summary:

    Corrected in previous revision

    This appears to have been an issue against the adopted specification draft. It does not apply to either of the formally published revisions 1.0 or 1.1.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

lack of Union construct (MER + ASIST)

  • Key: XTCE12-208
  • Legacy Issue Number: 8909
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Programming construct does not fit current data model, defer to future revision

    Not all ground systems support the union construct in the decommutated data. By specifying overlapping locationInContainer positions, the effect of the union can be achieved in XTCE. This feature request is being deferred to a future revision.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

inability to describe sets of limits (alarms) and conversions (polynomials)

  • Key: XTCE12-210
  • Legacy Issue Number: 8908
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Significant data model change, defer to future version

    This would be a significant change in the data model in order to support a capability that is already supported via the ParameterType inheritance mechanism. The requested feature can be handled by the database modeling tools and still exchanged using the mechanism in XTCE. The requested feature is being deferred for consideration in a future revision.
    What is called a mission phase here is called a context in XTCE. XTCE has a very robust capability to describe different alarms or calibrations in different Contexts.
    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 SpaceSystem will all have the same calibrations when the same voltage transducer is used. 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.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Re-architect XTCE alarm model

  • Key: XTCE12-55
  • Legacy Issue Number: 19369
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    XTCE alarms are associated with data types and come in a default and context set form. A variety of alarm types are associated with each data type, some specific to it (such enum alarms). However this is too restrictive to meet the needs of many of organizations. Specifically the following is requested: allow set of alarms without a required context by data type. Original reporter is JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Alarm definition architecture redesign postponed

    There is significant interest in do a redesign/move of alarm definitions. A number of fixes and improvements have been incorporated into XTCE 1.2. This helps correct specific problems for now. A redesign is to be postponed to an XTCE 2.x RFP when and if that is desired.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add OCL specific Algorithm to XTCE

  • Key: XTCE12-83
  • Legacy Issue Number: 14507
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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?

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Good idea, but out of scope for XTCE 1.2

    This is an interesting topic and would make sense to be evaluated in a later "2.0" type of RFP. We probably cannot tackle this now.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

AbsoluteTime should have Alarms

  • Key: XTCE12-120
  • Legacy Issue Number: 14466
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Not enough information yet to act on AbsoluteTimeDataType alarms

    This issue does not appear to be universally applicable at this time. With some proposals for use cases, it could be re-considered later. In the context of XTCE 1.2 it is chosen to defer this matter to a later time if it comes up again. At present, it does not appear that alarms of this type are needed.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Message/IncludeCondition/BaseContainer similarity

  • Key: XTCE12-129
  • Legacy Issue Number: 14460
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Defer to future model-based XTCE revision

    Simplification of the XTCE schema is a desirable goal, but would be better done in a new model-based specification for XTCE.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Add forward/reverse calibrator metadata

  • Key: XTCE12-116
  • Legacy Issue Number: 14473
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Not necessary to mark calibrators as forward/reverse

    The vast majority of calibrators can be computed in both directions without issue. There are some corner cases where it is much tougher. I propose that we do not need that in XTCE 1.2. Implementations that are relatively complete already exist for this purpose.

    Defer to a future XTCE RFP like a "2.0".

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Checkwindow not tied to context

  • Key: XTCE12-128
  • Legacy Issue Number: 14458
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Defer to future model-based XTCE revision

    Context is already an overloaded term in XTCE 1.1. Some existing users are using context for spacecraft lifecycle (integration & test, launch & early orbit, operations) and other groups are using it for spacecraft state (eclipse/non-eclipse, normal operations/safe mode, subsystem on/off). There are different dynamics for context alarms and context conversions when “context” is used in different ways.
    Recommend deferring additional complexity in the CheckWindow for commands until a new revision of the specification can distinguish between the different uses of spacecraft context.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Move Alarms outside of Type Area

  • Key: XTCE12-134
  • Legacy Issue Number: 14454
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Defer to future model-based XTCE revision

    There are trade-offs that were made between what was held at the Type level versus the Parameter level based on expected reuse of declared types. Most current implementations end up declaring a new Type for each Parameter, because the existing database models did not allow for detection of similarities. It is likely that a future revision of XTCE will use a new model that eliminates the distinction between Type and Parameter and simply allows reuse and extension of each Parameter as a base. Therefore addressing this issue is deferred to a future revision of XTCE, rather than disrupting current usage.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

CustomAlgorithm should be "typed" reference to AlgorithmSet

  • Key: XTCE12-85
  • Legacy Issue Number: 14505
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Propose to close this as out of scope in the XTCE 1.x design

    This refinement would introduce significant backwards compatibility issues and is probably not preventing a program implementation at this time. Propose to defer this to an "XTCE 2" type of proposal.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

Expand NameReference semantics

  • Key: XTCE12-98
  • Legacy Issue Number: 14489
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

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

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    Requires redesign of XTCE filesystem type path referencing

    This appears to be out of scope because it would be a dramatic change in the design of the file/path filesystem type syntax used for references. Not that it is a bad idea, but probably more of a "2.0" consideration.

  • Updated: Tue, 10 Jul 2018 14:22 GMT

ByteOrderList is invalid for Containers

  • Key: XTCE12-73
  • Legacy Issue Number: 14517
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    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.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Mon, 2 Apr 2018 18:22 GMT

Cleanup Container EntryList element by deprecating IndirectParameterRefEntry

  • Key: XTCE12-449
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The IndirectParameterRefEntry is a clever construct that has the potential to be useful, although I am not aware of anyone who has used it.

    I suggest that we consider removing it because it is a limited case of the more general case solved by the IncludeCondition element. The IncludeCondition can provide this functionality and a lot more. As a result, this element is effort for implementers that doesn't add anything really "new". In addition, it leaves a case where the need is addressed in more than 1 way - which is generally not the best idea.

  • Reported: XTCE 1.1 — Tue, 30 May 2017 23:44 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Mon, 2 Apr 2018 18:22 GMT

Re-evaluate the characterWidth attribute in String types

  • Key: XTCE12-484
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I am not sure that this attribute makes sense in the String data type definitions. The character encoding (@encoding) element really should capture the knowledge here, but there could be a nuance I am unsure about.

    Check on this in the committee meeting. Propose to remove the attribute.

  • Reported: XTCE 1.1 — Sat, 9 Sep 2017 18:22 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add event message support

  • Key: XTCE12-39
  • Legacy Issue Number: 19388
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Even message support is need in XTCE. Adding an EventSet to TelemetryMetaData would be an appropriate location.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Mon, 2 Apr 2018 18:22 GMT

Missing a number of changes and enumerations in ErrorDetectCorrectType children

  • Key: XTCE12-474
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The reworked XTCE 1.2 from the proposed BitBucket schema has additional checksums (also hashes) and a new XOR element. In addition, there is a missing @parameterRef that should appear to specify the parameter that holds the value. Some systems do not store that so it can be optional.

  • Reported: XTCE 1.1 — Sat, 5 Aug 2017 18:04 GMT
  • Disposition: Deferred — XTCE 1.2
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Mon, 2 Apr 2018 18:22 GMT

Calibrator selection using raw value

  • Key: XTCE12-396
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    We use a piece-wise polynomial calibration to approximate the Steinhart-Hart equation for thermistor response.
    That is, one polynomial is used when the temperature is low (and A/D counts are high) and another polynomial is used when the temperature is high.
    The switch point between the two polynomial calibrators is expressed in raw A/D counts.

    Using a ContextCalibrator (as currently defined) doesn't help as much as one would expect. ContextCalibrator context selection can use the raw value of a parameter instance (via useCalibratedValue=false) to determine context. The problem is that a specific parameter must be referenced in the match criteria; there is no mechanism to specify/reference generic input to the calibrator. This means we need to specify a separate parameter type for each thermistor parameter in order to specify the switch point. This creates an enormous amount of redundant declarations (the polynomials and switch points are identical for each parameter type, only the name of the parameter instance is changed) and somewhat circular logic (behavior of the parameter type is dependent on the parameter instance).

    Should have a mechanism to directly reference the raw counts at the parameter type level.

  • Reported: XTCE 1.1 — Mon, 5 Dec 2016 22:15 GMT
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:
  • Updated: Tue, 6 Dec 2016 17:42 GMT