Section 6.2.2 has a discussion on how to put VCID information in packet descriptions.
VCID or virtual channels are from "farther up" in the telemetry stream – essentially "packets travel over one or more vcids" ..

And they often not associated with packet definitions (as is the case with gsfc) by many institutions.

However some may wish to do and this section offers an approach.
Confusingly some of the examples show another approach without explanation.

This needs to be cleaned up.

Update Section 6.1 to better explain what "additional rules" were intended to mean.

In fact they are largely illustrative "recommendations" and not rules per se because they were found to be hard to implement in xpath – and more importantly – perhaps not universal in nation institution...

Essentially reflecting GSFC's way of doing things and so meant to be something each institution could customize ...

The UML diagrams in the original document were hand-drawn using the builtin Microsoft Word's drawing tools.

C2MS and other SpaceDTF documents have migrated to UML based diagrams produced using MagicDraw.

Specifically this refers to Figure 6.1 and Figure 6.2 in the document.

The XUSP 1.0 table followed the entire syntax tree of XTCE, and in so doing rules were output at each match the in tree path.

But XTCE is highly repetitive. To shorten the output the tree was pruned at certain paths that had already been output (e.g. @name appears early in the output, the rule is output 1 time there but not again, etc...)

Even with a lot of hand tuning and pruning the resulting table is 1000s of lines long.

In reality this method produces a lot of duplicate rules and an implementation should consolidate the rules into a small table of executable rules by reading the table and sorting/removing duplicates.

Or the table is published in its reduced an normative form.

The reduced form is something over 100 concrete rules.

These rules are written in XPath 2.0. They have been tested for syntax errors using software, and correctness using XML unit tests and a software tester.

Likewise they have been hand-tested by following the rules, and using them to guide the editing or updating of the XTCE 1.2. xsd into a non-normative GovSat 1.1. xsd corresponding those rules.

Section 6.1.1 Table Format needs to be updated to the new more concise table proposed for XUSP 1.1.

The old table followed the entire syntax tree of XTCE, in so doing rules were output at each match the in tree path. But XTCE is highly repetitive. To shorten the output the tree was pruned at certain paths that had already been output (e.g. @name appears early in the output, the rule is output 1 time there but not again, etc...)

Even with a lot of hand tuning, and pruning the resulting table is 1000s of lines long.

In reality this method produces a lot of duplicate rules and an implementation should consolidate the rules into a small table of executable rules.

Or the table is published in its reduced an normative form.

This section needs to refer to that table.

Section 6.1 refers to XTCE 1.1, uses the term "GovSat" and references the XUSP 1.0 rules tables.

These need to be adjusted for XUSP 1.1.

These sections need minor updates to XTCE version numbers, improved text in some cases and word definition update... mainly.

The introduction is a little out of date and needs some sprucing up. It refers to XTCE 1.1, and used the term "gov sat" which was the original name of the spec. It needs some minor cleanup and smoothing out.

Small edits associated with cover page, copyright and footer.

Line by line or section by section changes to document.

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

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.

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

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.

The SCID should be a Parameter.

Purely variable strings are not supported.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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