64 char limited names seemed reasonable however many years ago and in general this is true, nonetheless in our various GSFC conversion efforts we have consistently found a few parameter names that are longer. Usually this is in reference to a "flattening" process from a long complex type style definition to a single long dotted and array subscripted name. The result in a few cases of an overall database is greater than 64.
Most systems also seem to provide a way to make a shorter global "alias" so while holding these long named items in some internal table.

Nesting should be allowed.

Need to determine if nesting should be limited/constrained to prevent unlimited nesting.

Distress as an alarm severity is part of AstroUX guidance and also is a severity level in portions of C2MS.

Mention of Distress is here:
https://www.astrouxds.com/platforms/astro-for-r2c2/#xtce-alarm-levels

XTCE mentions:

Typical implementations color the "normal" level as green, "warning" level as yellow, and "critical" level as red.

As such, XUSP should allow the use of critical.

In alignment with the XTCE specification and Space DTF standardization, the severe alarm level should not be used. The substitute alarm level should be critical going forward.

None is not a level in XTCE 1.2
Severe is not a level in XTCE 1.2

This captures small edits throughout the spec document including changing XTCE 1.1 to XTCE 1.2, dates or small grammar edits.

The SCID should be a Parameter.

Missing the word, "of" between "instances" and "this" in "...Interlocks apply instead to any Commands that may follow instances this MetaCommand."

Purely variable strings are not supported.

AlarmMultiRanges feature was added in XTCE 1.2. This feature should not be included in the XUSP 1.1 update since is too complex for the target alarm model.

ParameterToSet/Derivation is a MathOperationType which is abstract. Which means you can make an instance of it.

A simple fix is to make a DerivationType extending MathOperationType.

ParameterToSet/Derivation is a MathOperationType which is abstract. Which means you can make an instance of it.

A simple fix is to make a DerivationType extending MathOperationType.

"There are eight different verifiers each associated with *difference* states in command processing"

Since the VCID is telemetered and is a standard CCSDS construct, suggest that supporting VCID be promoted to being supported first-class instead of via the AncillaryData construct.

Also, SCID and other transfer frame constructs should be similarly supported.

The following lines have xpath syntax errors and don't "compile" using Java XPath.

Bad #1 rule – @line 830 --> count(//@/@lastEntryForThisArrayInstance)=0
Bad #2 rule – @line 897 --> count(//xtce:CommandMetaData/*/xtce:DefaultAlarm
Bad #3 rule – @line 898 --> count(//xtce:CommandMetaData/*/xtce:ContextAlarmList
Bad #4 rule – @line 939 --> count(//xtce:CommandMetaData/*/xtce:DefaultAlarm
Bad #5 rule – @line 1019 --> count(//xtce:CommandMetaData/*/xtce:DefaultAlarm
Bad #6 rule – @line 1020 --> count(//xtce:CommandMetaData/*/xtce:ContextAlarmList
Bad #7 rule – @line 1044 --> count(//xtce:CommandMetaData/*/xtce:DefaultAlarm
Bad #8 rule – @line 1150 --> count(//xtce:CommandMetaData/*/xtce:DefaultAlarm
Bad #9 rule – @line 1151 --> count(//xtce:CommandMetaData/*/xtce:ContextAlarmList
Bad #10 rule – @line 1201 --> count(//xtce:CommandMetaData/*/xtce:DefaultAlarm
Bad #11 rule – @line 1202 --> count(//xtce:CommandMetaData/*/xtce:ContextAlarmList
Bad #12 rule – @line 1764 --> count(//@/@lastEntryForThisArrayInstance)=0
Bad #13 rule – @line 1805 --> count(//@/@lastEntryForThisArrayInstance)=0
Bad #14 rule – @line 2003 --> count(//@/@lastEntryForThisArrayInstance)=0

Several of the rules appear to have syntax errors, such as:

count(//xtce:CommandMetaData/*/xtce:DefaultAlarm

rangeForm attribute was added in XTCE 1.2. This attribute allows severity level between alarm ranges to be reversed (that is, rangeForm="inside" causes the more severe alarm ranges to inside of less severe alarm ranges). The rangeForm="inside" option not be included in the XUSP 1.1 update since is too complex for the target alarm model.

The XUSProfileRules.csv file contains extraneous spaces between commas. The spacing between commas is inconsistent it's mostly “, ,” but frequently “,,”. These spaces cause non-empty entries when the CSV file is imported into Excel.

Most names and fields in XUSP have added limits to the string length. There is no limit on the label size. I recommend that it match the mnemonic length of 64 characters.

The following 4 schema-types have funny character encodings for quotes or similar in a few lines of annotation, probably from Word editing.

BinaryArgumentType
BinaryDataType
BinaryParametertype
ServiceRefType

The errors are around "" items like "dangling reference" and some of the path related items.

approx. lines 20, 22, 26 and 58 per each file.

This makes some things complain – maybe compilers, Javadoc other tools.

The quick fix is to simply edit the schema and fix them, then motor on your way.

The published specification has extra whitespace in some of the columns. These should be removed before proceeding on updating the rules further.

This is a diff against the published version and proposed updates.

The XTCE 1.2 specification was approved by the DTC. The XUSP profile, which is based on XTCE, should be updated to use the Elements and Attributes of the XTCE 1.2 schema.