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

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

  • Key: XTCE12
  • Issues Count: 247
Open Closed All
All Issues

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<