1. 2014-04-01 Post-NASA Review Schema Harmonisation CCSDS Spring Meeting 2014 Peter Mendham, Richard Melvin, Stuart Fowell

2. SOIS EDS2014-04-01 2 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Overview Minor issues Namespaces and references Scalar type encoding Container encoding Type compatibility Calibrations, alarms and other non-functional data Toolchain-specific metadata Way forward

3. SOIS EDS2014-04-01 3 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Minor Issues Many minor syntactic issues Largely uncontroversial Most do not affect datasheet content Just the way it is expressed

4. SOIS EDS2014-04-01 4 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Namespaces and References Proposal to “flatten” namespaces Remove nested namespace elements in XML Removes semantic hierarchy of namespaces Hierarchy is now purely syntactic No more relative references Namespace, and other, references need clarification All namespace and type elements are separated by ‘/’ Difficult to parse unambiguously Use different separators? Known cases – global level Between namespace elements Namespace/type Known cases – component type level Interface/parameter Interface/command Container/entry Sub-component instance/interface

5. SOIS EDS2014-04-01 5 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Example Reference Separators Just some examples for debate Global level Between namespace elements “::” Namespace/type “::” E.g. ccsds::sois::SomeType Can use same separator as the last element is always a type and all prior elements form the namespace Component type level Interface/parameter “:” e.g. MyInterface:MyParam Interface/command “:” e.g. MyInterface:MyCommand Container/entry “.” e.g. SomeContainer.SomeEntry Sub-component instance/interface “/” e.g. MySubComponent/SubComponentInterface and MySubComponent/SubComponentInterface:MyCommand

6. SOIS EDS2014-04-01 6 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Scalar Type Encoding Encoding information on scalar types (i.e. not containers or arrays) is inconsistent and confusing Binary types and binary encodings should be dropped There should be no “cross-encoding” permitted An integer can only be encoded using an integer encoding A float may only be encoded using a float encoding Enforced by schema in a type definition Enforced by toolchain if encoding is being added at parameter declaration (type usage) stage Remove bit-order from encoding This is defined by subnetwork and cannot be controlled Verify this is the case? Simplify endianness to just big/little Rationalise float encodings Remove unnecessary constraints from float and integer type definitions Integers and floats do not need sizeInBits, range is sufficient Decision on underlying type is up to toolchain String encoding needs review, especially length handling (see next slide…)

7. SOIS EDS2014-04-01 7 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Container Encoding Number of odd cases which containers don’t handle well at the moment Segmentation of fields Was in XTCE but doesn’t directly translate as container model is different NASA/GSFC need for sub-field specification Outside the reference SOIS use cases/requirements Suggest a recognised EDS coding idiom is used (sub-containers) Current length field relies on repetition In general this might not be the case May want a length entry (with encoding) which contains the length, in bytes, of any entry such as a container Could also support a list of other entries This method would handle the length of strings well Could also apply the same pattern to error control… Error control not supported in containers XTCE mechanism is not fully thought through Doesn’t apply directly to SEDS Have an error control entry which specifies an error control algorithm (e.g. CRC, checksum, parity) and a list of entries to cover

8. SOIS EDS2014-04-01 8 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Type Compatibility Type compatibility is currently ill defined How different types relate What can be assigned to what What is valid when sub-typing (scalar type inheritance) What is valid when extending (container type inheritance) What encodings are valid to apply to what What semantics can be added to what What type do literals have What (if any) type coercion is supported Is there a need for type casting? Not a schema issue – rules to be applied and validated over and above the schema Will end up in Red Book only

9. SOIS EDS2014-04-01 9 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Calibrations, Alarms etc. Current split between schema elements/attributes and semantics is a functional/non- functional split Semantics do not affect the function of DAS or DVS components DVS has the function of transforming DAS data to DVS-level data Just like a calibration But could be stateful In the SOIS stack this is functional so is not described as meta-data Alarm limits would be non-functional So by this logic should be incorporated in the core DoT This would create attributes/elements to support this in the schema Calibrations are currently not supported, as expected these will be done functionally in DVS Do we need non-functional calibration information? But that gives two ways of doing the same thing Do we drop the functional representation of calibration and push calibrations into the DoT? How is DVS specified? How would that support stateful transformations? What about other transformations that are not calibrations but should be in DVS? This is an open point…

10. SOIS EDS2014-04-01 10 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Toolchain-Specific Meta-Data Do we need a mechanism for specifying toolchain-specific meta-data A bit like compiler pragmas Or annotations Could be generic Would be completely unstandardised Could easily lead to a horrible mess Lazy toolchain developers could push “hard” things into meta-data Would undermine entire efforts for interoperability If a reference implementation was available which did not need to use meta-data might help control the tendency of toolchain developers to fall back on meta-data through lack of understanding If no reference implementation available, suggest we do not introduce this capability

11. SOIS EDS2014-04-01 11 Presenter 1 & Presenter 2 Tuesday 9 April 2013 Way Forward Current SCISYS-NASA effort is focussed on harmonisation at the schema level only Address schema issues which arise directly as a result of NASA’s application Includes Syntactic issues Scalar type encoding Container support for segmentation and subfields Container support for error control May include Container support for length fields Name references Won’t include Type compatibility rules Semantic issues like alarms and (if applicable) calibrations