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

Thu Aug 7 06:55:34 UTC 2025

Dear Colin,

well, I must say it is more than I could expect. We actually worried already
how we are going to embed the different levels into actual Schema and how
they can be later on picked. Your mail I think covers all that, so for me
looks like it is well done. We should shortly discuss in our teleconference
next week (in that case it is rather medium well as of now?).

Cheers

Marcin

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Colin Haddow via
SMWG
Sent: Wednesday, August 6, 2025 10:33 PM
To: CCSDS Service Management W/G <smwg at mailman.ccsds.org>
Subject: [cssm] CCSDS Service Management - Action Item 250612-03

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.

1.	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>

2.	 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>

3.	 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/20250807/49156534/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20250807/49156534/attachment-0001.bin>