Issues for Mailing list of the XTCE Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 8875: proposed schema change for documentation issue
Issue 8885: includeCondition in commandContainer issue
Issue 8905: lack of delta limits (MER + JWST)
Issue 8906: command side seems to be missing the ability to have repeat arguments (MER)
Issue 8910: lack of clean way to describe "system variables",
Issue 8911: lack of clean way to describe multiple documentary type items
Issue 8912: no tracking mechanism per PARAMETER for changes (no change log)
Issue 8913: Variable length command packets must be supported
Issue 8914: JPL MER schema supports "hardware commands
Issue 8915: JWST, non-CCSDS header commands, routing info
Issue 8916: XTCE Command "Permissions" model may not be generic enough
Issue 8923: proper reference formed weak
Issue 8924: Container/Argument/Stream/Type/etc
Issue 8925: Clarification is needed on Ref names "local" to a spaceSystem
Issue 8926: Ref rules should be spelled out
Issue 8928: sizeInBits
Issue 9199: CalibratorType
Issue 9200: CalibratorType (02)
Issue 9201: CalibratorType (03)
Issue 9202: SplineCalibrator
Issue 9203: ToString and Booleans
Issue 9205: NumericAlarmConditionTy
Issue 9207: MetaCommand
Issue 9208: Command/Parameter
Issue 9209: Verifiers
Issue 9210: Command verifiers
Issue 9211: ArgumentType / ValidRange
Issue 9212: UnitSet
Issue 9213: ParameterType
Issue 9214: Algorithm for derived
Issue 9215: Argument set
Issue 9216: CommandContainer/Entry
Issue 9217: BlockMetaCommandType
Issue 9218: Parameters
Issue 9219: SpaceSystemType
Issue 9220: Aliases
Issue 9223: NameType
Issue 10153: 1 - move initialValue and UnitSet to ParameterSet (ESA-08)
Issue 10154: Expand explanatory material
Issue 10155: Expand explanatory material related to "Figure 2"
Issue 10156: 4 -- Expand explanatory material related to "Figure 4"
Issue 10157: 5 -- Expand explanatory material related to "Figure 6"
Issue 10158: 6 - Add Delta Alarms to XTCE
Issue 10159: 7 - Expand explanatory material related to "Figure 2"
Issue 10160: 8 - Expand explanatory material related to "Figure 3"
Issue 10161: 9 -- Expand explanatory for certain terms, Data Type and Data Encoding Type
Issue 10162: 10 - Add indicator of operational status to XTCE (JPL-004)
Issue 10163: Change service set to either accept Messages or Container references
Issue 10164: 2 - Add Aggregate (similar to C-structure) type to XTCE
Issue 10165: Expand explanatory material for XTCE types
Issue 10166: 4 -- Add a name/short description to the argument's valid range set
Issue 10167: 5 - Expand explanatory material in Figure 1
Issue 10168: 6 - Figures 2-10 not referenced in text
Issue 10178: 1 - Add ability to describe general equations in Calibrator area
Issue 10179: NASA-013
Issue 10180: ESA-002
Issue 10181: ESA-010
Issue 10182: ESA-012
Issue 10183: ESA-013
Issue 10184: ESA-017
Issue 10185: ESA-018
Issue 10186: ESA-019
Issue 10187: ESA-020
Issue 10188: ESA-022
Issue 10189: ESA-023
Issue 10190: ESA-025
Issue 10191: ESA-042
Issue 10192: ESA-054
Issue 10193: ESA-055
Issue 10194: ESA-056
Issue 10195: ESA-065
Issue 10196: ESA-067
Issue 10197: ESA-068
Issue 10198: ESA-069
Issue 10199: ESA-072
Issue 10200: ESA-075
Issue 10201: ESA-077
Issue 10202: ESA-078
Issue 10203: ESA-079
Issue 10204: INPE-001
Issue 10205: INPE-003
Issue 10206: INPE-006
Issue 10207: INPE-007
Issue 10208: INPE-012
Issue 10209: INPE-013
Issue 10210: JPL-001
Issue 10211: JPL-002
Issue 10212: JPL-005
Issue 10213: JPL-006
Issue 10214: JPL-007
Issue 10215: JPL-008
Issue 10216: JPL-009
Issue 10217: JPL-010
Issue 10218: JPL-011
Issue 10219: JPL-012
Issue 10220: JPL-013
Issue 10221: JPL-014
Issue 10222: JPL-015
Issue 10223: JPL-017
Issue 10224: JPL-018
Issue 10225: JPL-019
Issue 10226: JPL-020
Issue 10227: JPL-021
Issue 10228: JPL-022
Issue 10229: JPL-023
Issue 10230: JPL-024
Issue 10231: JPL-025
Issue 10232: JPL-027
Issue 10233: JPL-028
Issue 10234: JPL-031
Issue 10235: ESA-003
Issue 10236: ESA-021
Issue 10237: ESA-024
Issue 10238: ESA-027
Issue 10239: ESA-028
Issue 10240: ESA-029
Issue 10241: ESA-030
Issue 10242: ESA-031
Issue 10243: ESA-033
Issue 10244: ESA-035
Issue 10245: ESA-036
Issue 10246: ESA-037
Issue 10247: ESA-043
Issue 10248: ESA-044
Issue 10249: ESA-046
Issue 10250: ESA-047
Issue 10251: ESA-049
Issue 10252: ESA-050
Issue 10253: ESA-051
Issue 10254: ESA-052
Issue 10255: ESA-057
Issue 10256: ESA-058
Issue 10257: ESA-059
Issue 10258: ESA-060
Issue 10259: ESA-061
Issue 10260: ESA-062
Issue 10261: ESA-063
Issue 10262: ESA-064
Issue 10263: ESA-066
Issue 10264: ESA-070
Issue 10265: ESA-073
Issue 10266: ESA-074
Issue 10267: ESA-076
Issue 10268: INPE-002
Issue 10269: INPE-004
Issue 10270: INPE-005
Issue 10271: INPE-008
Issue 10272: INPE-010
Issue 10273: INPE-011
Issue 10274: NASA-002
Issue 10275: NASA-003
Issue 10276: NASA-005
Issue 10277: NASA-007
Issue 10278: NASA-008
Issue 10279: NASA-009
Issue 10280: NASA-011
Issue 10281: NASA-012
Issue 10440: Division symbol

Issue 8875: proposed schema change for documentation issue (xtce-rtf)

JPL MER & JWST schemas have numerous ways to capture various types of documentation -- these include but are not limited to developer information, flight software information,  document info and so forth.  At this time XTCE has a LongDescription and ShortDescription and a few specialized areas of documentation -- that are simply not sufficient to capture the full scope of info held in the other schemas.   While it would be nice to specifically put elements into XTCE to allow the capture of this information in a formal way, there is at this time no agreement on what that would exactly be.   
 
Most of the information in question is of the form "tag: data" -- where the tag is simply the label for the data -- such as "Developer:  T.Hacker".   As such a simpler solution at the moment would be to extend the XTCE LongDescription to be unbounded and add an attribute to it to hold the tag information.  Because this element is part of a base type in XTCE used by most of the major types -- it will give users a large number of areas in which to capture their varied documentation.  In time as agreement is reached on specific types of documentation, the schema can be extended more formally..
 
--- Proposed Schema change to XTCE ---

 
<element name="LongDescription" minOccurs="0" maxOccurs="unbounded">

<annotation>

    <documentation>The Long Description is intended to be used for explanitory descriptions of the object and may include HTML markup. Long Decriptions are of unbounded length. Multiple long descriptions may be used to hold tagged information.</documentation>

</annotation>

<complexType>

<simpleContent>

<extension base="string">

<attribute name="name" type="string"/>

</extension>

</simpleContent>

</complexType>

</element>

Resolution:
A new Element "AncillaryData" was added to "NameDescriptionType" to address this issue.  NameDescription Type is the base type for Parameter, ParameterType, ArgumentType, Argument, ContainerType, Algorithm … basically all significant elements.  AncillaryData is itself contained within a 'Set' and is unbounded.  AncillaryData is named (so that each organization may uniquely name their set of AncillaryData, has a mimeType and an optional href to point to possible external data.  AncillaryData may be used for very simple data like CVS tags to complex data like sound files or even external applications. 

In metacommand container/commandContainer - the includeCondition only allows parameterRef,  it should also allow argumentRef.  
 
Here is an example from a simulated MER command that uses either an ARM or Elbow argument depending on the proceeding argument which is the motor_id... the arguments are different units as well.
 
-----
 
<CommandContainer name="CMD-MOTOR_Container">
 <EntryList>
  <ArgumentRefEntry argumentRef="motor_id"/>
  <ArgumentRefEntry argumentRef="distanceArm">
   <IncludeCondition>
    <Comparison parameterRef="motor_id" value="0"/>
   </IncludeCondition>
  </ArgumentRefEntry>
  <ArgumentRefEntry argumentRef="distanceElbow">
   <IncludeCondition>
    <Comparison parameterRef="motor_id" value="1"/>
   </IncludeCondition>
  </ArgumentRefEntry>
 </EntryList>
</CommandContainer>

Resolution:
The Container inheritance feature can be used to implement this requested feature.

Delta limits compare deltas between instances of a parameter and issue an alarm outside a certain threshold

This issue is a duplicate of  issue 10158 which is resolved.

CommandContainerSet does not have argumentRefEntry

Resolution:
Duplicate of 8886 which is deferred, since an expression of the desired capability is possible in XTCE using parameter references.  Originally it was thought CommandContainerSet should have argumentRefs,  however this was a misunderstanding of the area

 lack of clean way to describe "system variables", typically flags for tuning of T&C system processing  (JWST, some MER)
 
System specific tunable variables that are not telemetry, often simple boolean switches

Resolution:
For variables that are unique to a particular T&C system, there is no value in capturing them in XTCE, because XTCE is targeted to be an Exchange format.  XTCE authors recommend using a T&C specific data store.  Other items that are operator-set or derived on the ground may be defined as parameters without assigning them to a Container.

lack of clean way to describe multiple documentary type items usually of the form "tag: data" in the text such as:
     SoftwareDeveloper: <your name here>  (JWST+ MER)
 
Compared to these two missions, XTCE seems lean on documentation areas.  Allowing LongDescription to be unbounded and adding a 'name' attribute would help mitigate this issue.

Merged with issue 8875 to provide a more robust documentation capability.

 no tracking mechanism per PARAMETER for changes  (no change log)  (MER + JWST)
 
JWST uses CVS to check-in individual parameter description files, one per telemetry point.   MER uses a change-log mechanism built into the Schema itself, although it does not capture the exact delta between changes. XTCE doesn't preclude the use of the former but doesnt support the latter either.
 

Resolution:
New AncillaryData capability added for issue 8875, supports documentation of changes within a parameter.  Individual parameter storage in a version control system with a merge process or include skeleton is also possible.

MER allows variable length command packet at the TAIL of a packet only.  XTCE seems to support variable length packets at any location and is a super set of this functionality

Resolution:
Not sure what change is requested, since XTCE has a superset of the needed functionality.
Disposition:	Closed

JPL MER schema supports "hardware commands" which are non-CCSDS format commands between or two the low-level onboard hardware

Resolution:
XTCE is capable of defining either CCSDS commands or non-CCSDS commands.  XTCE has been expanded to support additional documentation of named elements per issue 8875.
Disposition:	Duplicate

JWST supports non-CCSDS header commanding similiar to JPL hardware commands in that they are (often) sent between processes or sub-systems onboard (precisely how this works is vague).   XTCE should be able to support non-header command construction easily as it doesn't know anything about headers per se, but this needs to be verified.   However capturing the ROUTING information for the command is not so clear.  In the case of JPL, information is captured as to which software module should process the command (task i believe, although it may be function itself -- kr).  

Resolution:
Capability is covered with changes resulting from issue 8875
Disposition:	Duplicate

XTCE seems to mostly view command issuance from an uplink side, however MER and JWST seems to include mission phase, flight rules, ground rules and command restrictions together before a command may sent.  In addition there is the concept of forbidden commands in MER which means they may never be sent.  JWST has a similiar concept although in each case these forbidden commands may actual be sent somehow.  XTCE may need expansion in this area.

Resolution:
This is related to issue 8908 in that it is simply a nomenclature issue; what is called a mission phase or flight rules or ground rule here (and in many Boeing missions) is in XTCE called a '.Context'.  XTCE has a very robust capability to describe different Command 'Significance' in different Contexts.  Close, no change.
Disposition:	Closed

the documentation on how a proper reference is formed is weak.   As best as I can tell, the text quoted below is the ONLY place the "Unix-style" reference is mentioned in the entire XTCE document under parameterRefType. This annotation only shows up sporadically parameterRefTYpe is often extended or is an attribute.

Resolution:
This is true, and the documentation for references needs to be strengthened both in the schema and in the accompanying documentation.

Revised Text:
Replace:
	<simpleType name="NameReferenceType">
		<annotation>
			<documentation xml:lang="en" >Used when referencing a directory style "NameType".   No characters are prohibited.</documentation>
		</annotation>
		<restriction base="string"/>
	</simpleType>
With:
	<simpleType name="NameReferenceType">
		<annotation>
			<documentation xml:lang="en">Used when referencing a directory style "NameType".   All characters are legal.  All name references use a Unix 'like' name referencing mechanism across the SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage) where the '/', '..' and '.' are used to navigate through the hierarchy.  The use of an unqualified name will search for an item in the current SpaceSystem first, then if none is found, in progressively higher SpaceSystems.  A SpaceSystem is a name space (i.e., a named type declared in MetaCommandData is also declared in TelemetryMetaData - and vice versa).</documentation>
		</annotation>
		<restriction base="string"/>
	</simpleType>

Disposition:	Resolved

 Container/Argument/Stream/Type/etc... -- ALL refs (anything that's a sibling of NameReferenceType?) *should* follow the same format

Resolution:
Merged with issue 8923 (cleanup of parameterRefType documentation)
Disposition:	Duplicate

Clarification is need on Ref names "local" to a spaceSystem and in one area (telemetry/command) vs when crossing "bounderies".  For example, is a simple name sufficient in ParameterEntryRef in the TelemetryMetaData/ContainerSet when refering to a parameter in same TelemetryMetaData/ParameterSet area?   How 'bout when crossing from the command area to the telemetry area?  Certainly when crossing over to another spaceSystem... ?

Resolution:
Merged with issue 8923 (cleanup of parameterRefType documentation)
Disposition:	Duplicate

Ref rules should be spelled out then!  Ex.  Is it legal to ref a container in the command area with one defined in telemetry?  Is it legal to ref a metacommand/commandcontainer in another metacommand/commandcontainer?     Is the RULE really that you add "just enough" path information to fix up name collisions in your document?  OR are we forcing everyone to build all the refs with paths?   What about relative paths?     We should be clear as a bell on all

Resolution:
Merged with issue 8923 (cleanup of parameterRefType documentation)
Disposition:	Duplicate

sizeInBits is a an attribute in most of the parameterType elements and is an attribute that specifies the HOST SIDE storage length.


  
Further into the decode area there is another sizeInBits which is the "on the wire" size ...


  
Two questions really:


  
1 -- Does it really make sense to specify host storage sizes for a parameter?   It seems to me that this is not important for exchange as long as the host can HOLD parameter,  it doesn't really matter how they do it... (they may not even hold parameters in a standard built-in type in their language but use some other construct)


  
2 -- If the decision is made to keep it, would help to have a slight name change in one vs the other to help clarify its intended use?

Resolution:
sizeInBits has value where the Parameter does not originate from a telemetered source (i.e. it is a derived Parameter or is simply used on the T&C side only).  While the name 'sizeInBits' is duplicative of the Encoding sizeInBits, since their contexts are different, no name change seems necessary. 
Disposition:	Closed

Textual calibrations are not represented as calibrators. It would be interesting to put the textual  calibrator in the same set as spline calibrator. Actually, the textual calibration is represented  by a ToString element. At least this element should have a name, a short description attribute such that there will still be a  possibility to recover original names. The best solution would be to integrate ToString element, enhanced with name and short description attributes, to the  normal set of calibrators. 

Resolution:
This is related to separate calibration and alarm sets. A schema change will be submitted by ESA on another issue.
Disposition:	Duplicate

Spline calibrators and polynomial calibrators, as well as all other calibrators should have a short description attribute for documentation and human readable information storage. A name attribute would allow to keep original calibrator ids during conversion

Calibrators (either text, polynomial or spline) may be reused between parameters, and they 
always have to be defined in relation to a parameter type. This may imply copy paste work during conversions. It should be easier and clearer to define calibrators in a separated set, at  the telemetry or/and command level, and to references them when needed. This solution would  have the avantage to shorten the length of the XTCE file, and avoid copy past of similar contents. 

Resolution:
Duplicate of issue 8908, part of that issue is deferred.
Disposition: Duplicate

In SCOS 2000, a calibrated value has an engineering format and a radix attached to itself. 
        These concepts are not supported by XTCE. For a proper conversion it is interesting to have an engineeringFormat attribute, and a rawRadix attribute. The engineering format can be signed/unsigned integer or real. The radix is only applicable to unsigned integer parameter value and can be decimal, hexadecimal or octal. 

Resolution:
Unsigned integer values are allowed to be prefixed with 0x or 0o in order to indicate a hexadecimal or octal value, respectively.  The assumed radix is decimal.
Disposition: Closed

Boolean parameter can have a textual calibration in XTCE. For Boolean there is no ToString 
element but two attributes: oneStringValue and zeroStringValue. Even if this solution is 
acceptable it contradicts other textual calibrations (ToString elements) and cause problems for conversions. It is absolutely necessary to have these two attributes? Would not it be possible to use the ToString element for Boolean parameters?  Moreover, for boolean parameters, the unit set is always empty it does not have any sense (a boolean can only be a flag..). 

Resolution:
Issue is a duplicate of 10174 which is deferred.
Disposition: Duplicate

Alarms in XTCE are only available for parameters of type integer or float. In SCOS 2K, alarms 
are defined for any type of parameter. Moreover alarms in S2K can be of several types: soft  limit - hard limit- delta check - status consistency (linke to relevant telemetry parameter) - event generation - or application specific. For this reason a attribute or element describing the  type of the alarm (proprietary list or constrained value list) would be the best. 

Resolution:
Alarms have been defined for all parameter-types in telemetry.  
Revised Text:
Changes were affected by Validity issue 10185 and are shown in that section.
Disposition: Resolved

A TC & TM database may contain specific information about telecommands. In particular, the source of the telecommand can be indicated (like if it has been produced by a planning  software or smth else). 
        
SCOS has a flag to say if the current command can be executed alone, manually, or only as 
part of a command sequence. This flag cannot be translated in XTCE. 
The priority of the command cannot be represented (only the criticality). This is a new potential attribute for the metacommand element

Resolution:
This sort of "flag" information is very specific to particular implemenations and as such no clear way is given in XTCE to handle it.  The preferred way at this time is to hold that information in a system unique document, or in a system unique way in XTCE.  In either case, that type of information must be documented before given to another party.  Duplicate of 8910 which was closed with no changes.
Disposition: Duplicate

It is possible to set a default value (i.e. initial value) for a command parameter in XTCE, but in SCOS 2K, the default value is sometime expressed in the engineering format. And XTCE 
does not support the engineering format for the default value. XTCE should allow default value  in engineering (calibrated) format and give a way to deduce the format of the default value

Resolution:
Add Boolean flag to determine if initialValue is calibrated or not.  Add "typeless" initialValue to parameter so initialValue can be stored as String.  ESA submitting proposed Schema change

Command verifiers should have name and short attributes if possible. They could even be 
defined in a set, and integrated into a command through the use of references (this would even be faster and shorten the length of XTCE, and improve XTCE reuse as well). Those fields are needed because in SCOS 2K verifiers are labelled with a description and an id (ie. Name). 

Resolution:
CommandVerifierType was changed to be an extension of the OptionalNameDescriptionType so that it would allow an optional name and short description.

SCOS 2K allows tolerance (range check) during the command verification check. The tolerance check is not supported by XTCE. Basically a plus/minus value added to the value to be checked is the tolerance valid range. This can be represented in XTCE either by a valid range (that exists already for other elements, with min and max values) or by a unique attribute (tolerance) that will be added or deduced to/from the value to check. 

Resolution:
CustomAlgorithm and CheckWindow elements were added to the CommandVerifierType

XTCE allows a single valid vange for argument value. SCOS 2K allows multiple valid ranges 
for argument values and these cannot be represented in XTCE. For example, if there are two discrete ranges for the argument then XTCE fails to represent this. 
 Moreover in SCOS, range set are caracterized by a name, a short description, a flag 
identifying the expression used (calibrated or not), a radix (flag identifying the radix used for the range values specified in value list, applicable for unsigned integer values, can be decimal - hexadecimal or octal) 

Resolution:
ValidRangeSet added.  

The parameter unit in XTCE is attached to the parameter type. In SCOS, it is not easily 
possible to define them here and it would be easier to place the unit in the parameter definition (because SCOS uses PUS based parameter types). With the unit in the parameter properties, the parameter type set will be shorter, and would then describe only PUS parameter types for example. Actually there is one parameter type per parameter instance, which is not ideal

Resolution:
Duplicate of issue 10153.
Disposition:	Duplicate

It would be great to define PUS (C-Telemetry and telecommand packet utilization, ECSS-E-70- 41A, 30 Jan 2003, chapter 23 ) parameter types and then extends these types for the need of the database. This means that there should be a way to derive parameter types, or extend  them (the same concept exists already for containers). With this extension, the parameter type set would be much smaller than now and simpler to understand. 
A way to provide this is to add an attribute to a parameter type that allows to reference another parameter type. 

Resolution:
Added "baseType" to allow inheritance mechanism of types

In the schema it is not very clear where to add the algorithm used to compute derived 
parameters. As the derived attribute is set in parameter properties, the only place to add the  algorithm is under this element. But the only reference or implementation of an algorithm in the  parameter properties is under validity condition/ custom algorithm which is not really the best  place. Has the derived algorithm been forgotten by the author or where is it? In relation to SCOS this is where the content of synthetic parameter is copied (the expression for the 
derivation). 

Resolution:
Definition of a schema for complex derivation algorithms was intentionally left out of the XTCE specification.  It is possible to use a simple algorithm (arithmetic combination of two parameters) or reference a named algorithm that is externally defined.

A spelling mistake must be corrected in the Argument Definition. It concerns ArgumentArrayType (and is actually ArgumementArrayType). 

Resolution:
ArgumentArrayType is now spelled correctly

When building a command, SCOS has a second possiblity to set default values. Default 
values cannot be set while the command is being built (in the entry list). SCOS supports the 
following at this stage: the default value, the type of the default value (calibrated or not). 
        
Dynamic default values (through telemetry parameters look up) are also possible in SCOS,  but cannot be represented in XTCE. To do this, a reference to a TM parameter should exist for  the command argument

Resolution:
Added initialValue override for Parameter and Argument.

Block meta command, namely command sequences support, is not satisfactory for SCOS  ASCII MIB. There is not enough details, and sequences cannot be described in XTCE. 

Resolution:
Duplicate of issue 10186 which is closed without change.  Command sequences (beyond simple sequences that can be defined within a container) are to be considered by other specifications.
Disposition:		Duplicate

At present there is no entry type available to define the complementary or redundant data. I.e.  TM parameter Battery1TempA has redundancy parameter Battery1TempB, and TC 
Battery1Disconnect has complementary TC Battery1Connect. 
 For Telecommands and Telemetry Parameters & Packets a list should be added where can be added the names of the redundant or complementary data related to that data. A list is needed as there might be multiple entrys of each. 

Resolution:
Duplicate of 10169 which is deferred due to complexity.
Disposition: Duplicate

Defining the model type to which space elements are applicable, i.e. SVF, EM, PFM, etc are 
not available. 
 For each system element include a list where the models for which this system element are 
valid are include. All elements of that system element are then valid for all the models in the 
list (Engineering model, thermal model, flight model, system verification facility, etc). 

Resolution:
Duplicate of issue 10162 which is resolved.
Disposition:	Duplicate

:        Aliases do not seem to inherit through the space-system elements like names, i.e. 
        Sat1/power/bat1/voltage may have alias of 012 within the bat1 alias set and should have 
        something like S1PB1012 within the system alias set, so that it is unique within the subsystem 
         and whole system? 
        
        Aliases may inherit names through the space system elements, however for this to happen 
        the alias for each system element needs to be available. So an alias entry needs to be 
        provided for each system-element unique in its hierachical position. I.e. B1 for battery1, P for 
        Power, etc. This could be an alias list at each space system element. 

Resolution:
There are intentionally no restrictions on alias naming.  Enforcement of a particular alias naming scheme however is system dependent and not related to definition exchange other than the documentation of the naming scheme which is allowed in the SpaceSystem definition.

Aliases, Long Description and Short Description are not available with all major data types, i.e. Calibration curve. 
        
For consistency all the important data types should be able to have alias, long description and short description associated to them, even if they are not all necessarily populated. 
Depending upon the database providers so rather than others will be populated

Resolution:
The NameDescriptionType (see issue 9200) has been included in almost all the major elements.  If any are missing, they need to be added.  This type is now in Calibrator for example.  Any other areas should be submitted with proposed Schema change.

Schema Change in XTCE 1.1:  initialValue of type "string" created in ParameterSet area, overrides ParameterType area, format flexible for ParameterType.

Resolution:
initialValue of type "string" created in ParameterSet area, overrides an initialValue supplied in the ParameterType area, format flexible for ParameterType. 

2 - Expand explanatory material on the differences between Telemetry and Command Parameters in XTCE (ESA-032)

Non-normative portion of XTCE 1.1 specification extended

Resolution: 
Non-normative portion of XTCE 1.1 specifications extended

3 - Expand explanatory material related to "Figure 2" in the non-normative part of the XTCE specification (ESA-039)

Extended in XTCE 1.1

Resolution: 
Explanatory non-normative text extended in XTCE 1.1

4 -- Expand explanatory material related to "Figure 4" in the non-normative part of the XTCE specification (ESA-041)

Expanded in XTCE 1.1

Resolution: 
Explanatory non-normative text extended in XTCE 1.1

5 -- Expand explanatory material related to "Figure 6" in the non-normative part of the XTCE specification (ESA-053)

Expanded in XTCE 1.1

Resolution: 
Explanatory non-normative text extended in XTCE 1.1

6 - Add Delta Alarms to XTCE (ESA-016)

Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area

Resolution:  
Delta Alarms support added in XTCE 1.1, in the ChangeAlarm area
add the following