[cssm] CCSDS Service Management - Action Item 250612-03

[Colin Haddow]

Dear all,
               with respect to CCSDS Service Management - Action Item 250612-03 "Develop concept of how to the potential need to have different configurabiltiy levels used in service management SACP -- e.g., different name space (related to XML schema being generated from the FRM)", Holger and I have done some work on this and have come up with the following approach.


  *
On how to get the required annotation information about the configurability levels into the FRM model Holger is of the opinion that, as the spreadsheet being used by Erik, Marcin et al to capture the appropriate levels for the FRM parameters was generated from the FRM model then it should be no big deal to create a script that takes the configurability level information out of the spreadsheets and inserts the appropriate annotation into the FRM model. The configurability level should be captured in the spreadsheets as a comma deliminated list, i.e. 1,2,3 etc. where the numbers reflect the configurability levels as agreed at the Baltimore meeting, viz;


Term

Value

Comments

NotExposed

0

Functions and/or parameters of the FRM that are only of concern the provider

PerCatalog

1

Functions and/or parameters of the FRM that a provider defines in their service catalog

PerAgreement

2

Functions and/or parameters of the FRM that are captured in the Service Agreement

PerProfile

3

Functions and/or parameters of the FRM that are in the configuration profile

PerPackage

4

Functions and/or parameters of the FRM that are configurable on a service package basis

DuringExecution

5

Function and/or parameters of the FRM that are configurable during execution of a tracking pass


  1.
The annotation in the FRM model would be included XML schemas generated from the model (and this would still allow the specification of a namespace). The annotation would appear in the generated schemas as illustrated in the following example;

<xsd:complexType name="AntResourceStatNamed">

    <xsd:annotation>

      <xsd:appinfo source="notExposed">
        <![CDATA[true]]>
      </xsd:appinfo>

      <xsd:appinfo source="SemanticDefinition">
        <![CDATA[This enumerated parameter reports the overall status of the antenna and can take on four values:
- 'configured':  the antenna system has been configured, but is not yet tracking because it is still moving to the initial pointing or the spacecraft is not yet or no longer in view;
- 'operational':  the antenna is tracking in the reported pointing mode (cf. antennaPointingMode);
- 'interrupted':  a failure has been detected that prevents the antenna from tracking nominally;
- 'halted':  the antenna has been taken out of service, e.g. due to wind speed requiring the antenna to be put into stow position.]]>
      </xsd:appinfo>

      <xsd:appinfo source="perCatalogue">
        <![CDATA[true]]>
      </xsd:appinfo>

    </xsd:annotation>

    <xsd:complexContent>

      <xsd:extension base="ParameterBaseType">

        <xsd:attribute name="value" type="AntResourceStat" use="required"/>

        <xsd:attribute fixed="antResourceStat" name="classifier" type="xsd:string"/>

        <xsd:attribute fixed="1.3.112.4.4.2.1.10100.1.1.1.1" name="oid" type="ObjectIdentifier"/>

      </xsd:extension>

    </xsd:complexContent>

  </xsd:complexType>


  1.
 An XSLT stylesheet(s) would then be used to filter out (whitelist) only those parameters that met the appropriate filter criteria, e.g.;


     *
Levels 3,4 and 5 to be generated for configuration profile
     *
Levels 2 to be generated for service agreement.

For the time being the same namespace would be used for all filtered FRM schemas as neither Holger or myself could come up with a good reason for different namespaces and the use of these can make life more complicated. An example of a possible XSLT stylesheet (from some quick prototyping with the aid of chatGPT) is shown below;

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"

  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

  exclude-result-prefixes="xsd">

  <!-- Root template: start processing at the document root -->
<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>

  <!-- Template to copy only elements that contain BOTH desired xsd:appinfo elements -->
<xsl:template match="*[

    xsd:appinfo[@source='notExposed'][normalize-space(.)='true']

    and

    xsd:appinfo[@source='perCatalogue'][normalize-space(.)='true']

  ]">
<xsl:copy>
<xsl:apply-templates select="@*|node()" />
</xsl:copy>
</xsl:template>

  <!-- Do NOT copy anything else (elements without both required xsd:appinfo children are ignored) -->
<xsl:template match="node()|@*" />

</xsl:stylesheet>


  1.
 The XSLT stylesheets could be applied to the schemas files by means of a python script (again rapidly prototyped with chatGPT during a telecon Holger and I had). The prototype script is shown below;

from lxml import etree

# Input and output file paths

input_xml_file = "input.xml"

xslt_file = "filter.xslt"

output_file = "output.xml"

# Load the XML and XSLT files

with open(input_xml_file, 'rb') as f:

    xml_doc = etree.parse(f)

with open(xslt_file, 'rb') as f:

    xslt_doc = etree.parse(f)

# Create an XSLT transformer

transform = etree.XSLT(xslt_doc)

# Apply the transformation

result_tree = transform(xml_doc)

# Save the result to a file

with open(output_file, 'wb') as f:

    f.write(etree.tostring(result_tree, pretty_print=True, encoding='UTF-8', xml_declaration=True))

print(f"Transformation complete. Output written to '{output_file}'")

<xsd:appinfo source="notExposed"> <![CDATA[true]]> </xsd:appinfo> <xsd:appinfo source="perCatalogue"> <![CDATA[true]]> </xsd:appinfo>

If this approach is acceptable Holger will start working on the import of the parameter classifcation back into the FRM model and I'll do some more prototyping of the filtering. Subject for discussion at the next telecon ?


Cheers for now,

Colin



Dr. Colin R. Haddow

Scotty Consulting UG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20250806/f1c26835/attachment-0001.htm>