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.

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

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.

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.

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.

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.

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.

Please specify that this is for earth orbital missions

No Data Available

In 6.2.3.2, specify that the XML snippet is an exemple and unbold the text between the two xml snippets.

Unbold the text. The XML sequences are already referred to as examples in the text

The schemaLocation is wrong, it should be (I guess) http://www.omg.org/space/xtce/SpaceSystemV1.1.xsd
By the way, this file does not exist (today) and it should be an officiel OMG URL
This template seems too loose a definition for something normative.
For instance: "Each user based on their mission must change some items. This includes items such as..." there is here a need to list all the items.
Couldn't it be possible to standardize an XSD defining this template and, btw, including other rules?

Updated schema location to:
http://www.omg.org/spec/XTCE/20061101/06-11-06.xsd

Section 6.1.2 is non normative since the excel file is normative. So, I propose to move this section to an annex and clearly state that this annex is non normative.

Delete Section 6.1.2. Table Summary (this is at the end of section 6, so there is no paragraph renumbering required).

The reference to XTCE_v1.1_GovSat Tailoring Guide_Rules Table file is problematic because this is not the wau the OMG store the files

The machine readable file containing the rules table will be formatted as a comma-separated value file format

The references to the machine-consumable files on the cover page and in section 6.1 of the XUSP specification should consistently refer to the file(s) by their assigned URL rather than just a file name and/or document number.

Replace file references on cover page and section 6.1 with assigned URLs.