<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Georgia",serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Georgia",serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 70.85pt 56.7pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Dear Marcin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">I took a look at the schema examples. No surprise, I think we have work to do : -)
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">I can very much appreciate the issue being dealt with here of how to have something that draws the configuration profile from functional resources in yet also fits
with the service management schema landscape. In some sense we have two very different things going on here (yeah, probably not really a surprise to you). My sense is that we would do well to lean towards the service management schema landscape in deciding
how we want to proceed. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Doing a quick compare and contrast, the current things we have out there for the service management landscape lend themselves to instance documents that are quite
straightforward. Putting some representative instance documents into a mind manager map file it quickly shows you the level of complexity/markup elements and sub elements involved for a particular instance. If I load up one of the CPIF instance from prototyping
I get a (partial) diagram like this:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><img width="949" height="600" style="width:9.8854in;height:6.25in" id="Picture_x0020_1" src="cid:image003.png@01D61FA9.32C406D0"></span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">The counts in the oval represent the number of items below this element in the map including item name and value. There is about 3 levels of hierarchy involved and
then we are done (eg., PlanningInfo</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">PlanningInfoData</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">elevationAscendingEvent</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">*payload*)
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">By contrast for either the multiple service or cookie cutter or service config profile so far we have a partial diagram like this:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><img width="1201" height="446" style="width:12.5104in;height:4.6458in" id="Picture_x0020_2" src="cid:image006.png@01D61FA9.32C406D0"></span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Which has a lot more levels of navigation before we finally get to the “payload” (ConfigurationProfile</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">serviceProfile</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">apertureFR</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">physicalChannelFR</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">functionalResourceParameters</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">sanaRegisteredFrParameter</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">stringParmaeter</span><span style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">*payload*).
I fear with something like this we are essentially dead on arrival. It seems to expose too much internal wiring/plumbing (and as I think you said, at the end of the day, ground station operators don't care at all about whatever wiring CCSDS has figured out
they just want to know the parameters to put into their equipment). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Perhaps we need to consider a more substantial transformation capability between the FRM and CSSM configuration profiles. I can’t help but wonder if this transformation
could get us to expressions of configuration profile that are much more “flat” and speak the user’s language much more directly. I don’t know what that transformation is yet, but a diagram kind of showing this might look like:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><img width="1214" height="746" style="width:12.6458in;height:7.7708in" id="Picture_x0020_4" src="cid:image007.png@01D61FA8.6ACFAC10"></span><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Given that, ultimately, the FRM is delivered/transferred to SANA as an XML instance document it seems that there should be the possibility of indicating the FRs that
going into a type of configuration profile and then xpath, xquery, etc to get to some list of parameters and their data types. It would imply some artifact such as database and/or spreadsheet that names the FRs for each configuration profile type. And I’m
sure this is where you come out and pat me on the shoulder and say “there, there…it will all be better soon” : -) Nonetheless, perhaps this helps at least a bit…? Let’s discuss more on Monday.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D">-Erik <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Georgia",serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal"><b>From:</b> SMWG <smwg-bounces@mailman.ccsds.org> <b>On Behalf Of
</b>Marcin.Gnat@dlr.de<br>
<b>Sent:</b> Friday, March 27, 2020 05:25<br>
<b>To:</b> smwg@mailman.ccsds.org<br>
<b>Subject:</b> [EXTERNAL] [cssm] SACP Schema Development - yet another Update<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Dear all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I just uploaded the yet updated schema-drafts and examples. This time the cookie-cutter example is filled with same information as the generic one, for beter comparison. Also I’ve split the main schema to 902x05w0_01-ConfPrfl.xsd and 902x05w0_01-ccConfPrfl.xsd,
to allow smoothly to validate respective examples, without any need for changes as proposed below.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Agreement%20and%20Service%20Config%20Profile/Schema%20Drafts/SACP_schema_development_20200327.zip">https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Agreement%20and%20Service%20Config%20Profile/Schema%20Drafts/SACP_schema_development_20200327.zip</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As next, I will try to work on “full-blown-example” of Schema and Example-Profile including also parameter validation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here I need to think if we stay with our SM-AbstractParameter as a base class, or I go for the FRM classes (is there any reference I can use for that? Any XSD with base classes I could use?).. What do you think?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Cheers and stay healthy<o:p></o:p></p>
<p class="MsoNormal">Marcin<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:DE">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;mso-fareast-language:DE"> SMWG [<a href="mailto:smwg-bounces@mailman.ccsds.org">mailto:smwg-bounces@mailman.ccsds.org</a>]
<b>On Behalf Of </b><a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a><br>
<b>Sent:</b> Dienstag, 17. März 2020 17:58<br>
<b>To:</b> <a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a><br>
<b>Subject:</b> [cssm] SACP Schema Development - Update<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="Gruß"></a><span lang="DE">Dear all,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal">I just uploaded the presentation and updated Schemas to the CWE:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="DE"><a href="https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Agreement%20and%20Service%20Config%20Profile/Schema%20Drafts/SACP_Schema_Discussion_20200312.pptx?Web=1"><span lang="EN-US">https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Agreement%20and%20Service%20Config%20Profile/Schema%20Drafts/SACP_Schema_Discussion_20200312.pptx?Web=1</span></a></span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="DE"><a href="https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Agreement%20and%20Service%20Config%20Profile/Schema%20Drafts/SACP_schema_development_20200317.zip">https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Agreement%20and%20Service%20Config%20Profile/Schema%20Drafts/SACP_schema_development_20200317.zip</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal">The example XML is autogenerated out of XSD and does not yet include some real parameters (I did that for the generic example already). I will fill it up next days, and upload, so that you can better compare the differences.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The section in the beginning of the main schema (902x05w0_01-ConfPrfl.xsd) needs to be changed, depending what content one needs (the cookie-cuter or generic one). So when you take examples (both point to the same main schema!) think about
changing the schema as well (otherwise you won’t get validated).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> <xsd:restriction base="SrvMgtInfoEntityType"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> <xsd:sequence><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> <xsd:element ref="configurationProfileHeader" minOccurs="1" maxOccurs="1"/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:red">Here, use this
</span><span style="font-size:10.0pt;font-family:Wingdings;color:red">à</span><span style="font-size:10.0pt;font-family:"Courier New""> <xsd:element ref="configurationProfileFwdRtnSlsTrnsServData" minOccurs="1" maxOccurs="1"/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:red">Or this
</span><span style="font-size:10.0pt;font-family:Wingdings;color:red">à</span><span style="font-size:10.0pt;font-family:"Courier New""> <!-- <xsd:element ref="configurationProfileData" minOccurs="1" maxOccurs="1"/> --><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><!-- we have a problem here!!! we can't restrict SrvMgtInfoEntityType with "choice", if we extend it, we have wrong schema (includes some other things then) --><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </xsd:sequence><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> </xsd:restriction><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I tried to overcome that, but didn’t manage. Whatever I did, sooner or later I hit some issue…
<o:p></o:p></p>
<p class="MsoNormal">This is one of the things we have, which I mentioned, when I said the cookie-cutters does not fit perfectly into current schema landscape (maybe its not immediately obvious, but when you look at my first diagram from the presentation, and
than come back to schema, you should see that). <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’d be glad if we can talk next time more about it. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hear you soon<o:p></o:p></p>
<p class="MsoNormal">Marcin<o:p></o:p></p>
</div>
</body>
</html>