<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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:tax="http://schemas.microsoft.com/sharepoint/taxonomy/soap/" xmlns:tns="http://schemas.microsoft.com/sharepoint/soap/recordsrepository/" xmlns:spsup="http://microsoft.com/webservices/SharePointPortalServer/UserProfileService" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:st="" 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 14 (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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
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.EmailStyle20
{mso-style-type:personal;
font-family:"Georgia","serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Georgia","serif";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 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="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Dear John and Erik,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I’m so happy this discussion is coming up
</span><span lang="EN-US" style="font-family:Wingdings;color:#1F497D">J</span><span lang="EN-US" style="color:#1F497D">. Finally we can get to something…<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">To the topic, Erik I think captured few of my concerns. On the other hand, I concur with John, that having everything in flat list would end up very fast in a mess.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">We need to find maybe some golden middle.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">The point of matching of the FR parameters and their definitions: I came up with “simple parameter based on AbstractParameter”, which however does not match to the FRM definitions. I understand on
one side where it comes from (ASN1 and SLE heritage), and may be good for some fancy wire protocols (like CSTS MD ;-), but I really wonder if anybody in a ground station does want to know how the specific randomizing is defined mathematically per FR definition,
in exchange of choosing just “randomizing on” or “off”. At the end, the ground station implementers will have to cope with changing from the FRM or SM abstraction layer into their physical devices they have, and they need to do some matching being done custom
way anyhow (the question is only how and at which level is it performed).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I know I’m possibly attacking a bit a concept of FRM and maybe I should earlier get a deeper look into that, but maybe earlier I would not be deep enough in Config-Profile stuff to see that anyway.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Let’s see how far we go with the discussion today. Unfortunately I did not manage to include John’s FRM-like schema into my examples, so no updates…<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> John Pietras [mailto:john.pietras@gst.com]
<br>
<b>Sent:</b> Freitag, 1. Mai 2020 22:42<br>
<b>To:</b> John Pietras; Barkley, Erik J (US 3970); Gnat, Marcin<br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org); Wolfgang Hell<br>
<b>Subject:</b> RE: SACP Schema Development - yet another Update (my earlier comments amended)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Erik,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I’d like to amend (slightly) a comment I made in the email below. I said that I got the impression from your example that one need to crawl the XML schema hierarchy to *<b>name</b>* the parameter,
and I pointed out that that’s not true. However, it *<b>is</b>* true that with the current schema/approach you do have to crawl the hierarchy to *<b>locate</b>* the parameter name, and I’m now thinking that that was your objection.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">However, that still does not negate the fact that for a configuration profile that addresses all layers of a CCSDS communication stack (aperture to SLE-TS, CSTS, or TGFT Host), for anything but the
simplest spacecraft (e.g., one MC. One VC and one MAP channel on the forward link, and one MC, one VC, and one RAF instance on the return link) there are going to be a lot of instances of the same parameter types, and there has to be some way of organizing
them. The current schema organizes this according to the fanning-in and fanning-out of the data flows through the various layers, which has the added advantage of inherently representing the wiring of the stack. There are ways to somewhat decouple the wiring
among the FRs and the parameters contained within those FRs, but (a) both parties still need to agree on that wiring in the first place and (b) someone then has to decide what’s the “right” order for the various data sets in the configuration profile – e.g.,
do I specify all of the master channel parameters for all of the master channel instances before I specify all of the VC parameters for all of the VC instances, before I specify all of the MAP Channel parameters for all of the MAP channels?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SMWG [mailto:smwg-bounces@mailman.ccsds.org]
<b>On Behalf Of </b>John Pietras<br>
<b>Sent:</b> Friday, May 1, 2020 3:50 PM<br>
<b>To:</b> Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov>; Marcin.Gnat@dlr.de<br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org>; Wolfgang Hell <wo_._he@t-online.de><br>
<b>Subject:</b> Re: [cssm] SACP Schema Development - yet another Update<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Erik,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I think that you are misinterpreting the containment hierarchy of the XML schema/document. One could get the impression from your example that to “name” a parameter you have to crawl the hierarchy.
That’s not true – e.g., the name of tcPlopSyncMaxCltuLength parameter of the TcPlopSyncAndChnlEncode FR (i.e., encoder) that appears in the configuration profile is {<FrNickname for the TcPlopSyncAndChnlEncode FR>: “tcPlopSyncMaxCltuLength”}. Rather than repeat
the <FrNickname for the TcPlopSyncAndChnlEncode FR> for every parameter, we leverage XML to let us collect all of the TcPlopSyncAndChnlEncode parameters under the same Nickname.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">You tend to draw your examples from the lowest couple of layers of the space communications “stack” (aperture, space link carrier, coding) where indeed in most cases there are only one instance of
each type of FR and therefore only one instance of each parameter of each FR. So for those layers, indeed, you can have a flat list of “ForwardProfileParameters”. And in fact the functional resource naming conventions give unique names to every parameter,
so for those parameters that appear once and once only in a configuration profile, one *<b>could</b>* just get away with using the parameter names (e.g., tcPlopSyncMaxCltuLength )and ignoring the nickname of the FR instances that contain them.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">However, when you get “above” the coding layer, then you start getting multiple instances of the same FR types, and each of those instances has its own “copy” of the configuration parameters that
applies to that instance. E.g., each one of possibly multiple master channels has its own set of configuration parameters, and each of the virtual channels of each of those master channels has *<b>its</b>* own set of configuration parameters, and (on the forward
link) each virtual channel has its own set of MAP channels, each with its own set of configuration parameters. We use the XML containment hierarchy to define, for example, which set of VC Generation parameters applies to the VC #4 that feeds Master Channel
0, and which set of VC Generation parameters applies to the VC #4 that feeds Master Channel 1. I think that your flat-list approach would get awkward dealing with these kinds of configuration parameters.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I look forward to Monday’s discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SMWG [<a href="mailto:smwg-bounces@mailman.ccsds.org">mailto:smwg-bounces@mailman.ccsds.org</a>]
<b>On Behalf Of </b>Barkley, Erik J (US 3970) via SMWG<br>
<b>Sent:</b> Friday, May 1, 2020 2:11 PM<br>
<b>To:</b> <a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a><br>
<b>Cc:</b> CCSDS Service Mgmt WG <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>><br>
<b>Subject:</b> Re: [cssm] SACP Schema Development - yet another Update<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">Dear Marcin,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><img border="0" width="949" height="600" id="Picture_x0020_1" src="cid:image001.png@01D62201.05E25900"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">PlanningInfoData</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">elevationAscendingEvent</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">*payload*)
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><img border="0" width="1201" height="446" id="Picture_x0020_2" src="cid:image002.png@01D62201.05E25900"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 0cm 0cm 0cm">
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">serviceProfile</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">apertureFR</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">physicalChannelFR</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">functionalResourceParameters</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">sanaRegisteredFrParameter</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">stringParmaeter</span><span lang="EN-US" style="font-size:14.0pt;font-family:Wingdings;color:#1F497D">à</span><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><img border="0" width="1215" height="747" id="Picture_x0020_4" src="cid:image003.png@01D62201.05E25900"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D">-Erik <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:14.0pt;font-family:"Georgia","serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SMWG <<a href="mailto:smwg-bounces@mailman.ccsds.org">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> Friday, March 27, 2020 05:25<br>
<b>To:</b> <a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a><br>
<b>Subject:</b> [EXTERNAL] [cssm] SACP Schema Development - yet another Update<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Dear all,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><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></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">As next, I will try to work on “full-blown-example” of Schema and Example-Profile including also parameter validation.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Cheers and stay healthy<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> 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"><o:p> </o:p></p>
<p class="MsoNormal"><a name="Gruß"></a>Dear all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">I just uploaded the presentation and updated Schemas to the CWE:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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_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 lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></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_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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">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></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""> <xsd:restriction base="SrvMgtInfoEntityType"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""> <xsd:sequence><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" 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 lang="EN-US" style="font-size:10.0pt;font-family:"Courier New";color:red">Here, use this
</span><span lang="EN-US" style="font-size:10.0pt;font-family:Wingdings;color:red">à</span><span lang="EN-US" 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 lang="EN-US" style="font-size:10.0pt;font-family:"Courier New";color:red">Or this
</span><span lang="EN-US" style="font-size:10.0pt;font-family:Wingdings;color:red">à</span><span lang="EN-US" 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 lang="EN-US" 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 lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""> </xsd:sequence><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""> </xsd:restriction><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I tried to overcome that, but didn’t manage. Whatever I did, sooner or later I hit some issue…
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I’d be glad if we can talk next time more about it.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Hear you soon<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Marcin<o:p></o:p></span></p>
</div>
</body>
</html>