<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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: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:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Marcin, thanks for looking this over and thinking about it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I agree with you that servicePackageStatus would be good to keep as an optional string, and that its values could be used by the provider to (optionally) provide additional information on the status of a package
(there should be no need to work out all the possible or permissible values now). Since the activeScenario flag in ScenarioDetails already covers the case of scheduled versus alternate, we should just make sure that ScenarioDetails is clearly described as
mandatory to be present when alternate scenarios are present.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="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"><b>From:</b> Marcin.Gnat@dlr.de <Marcin.Gnat@dlr.de> <br>
<b>Sent:</b> Friday, November 23, 2018 8:10 AM<br>
<b>To:</b> Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy@nasa.gov><br>
<b>Cc:</b> smwg@mailman.ccsds.org<br>
<b>Subject:</b> RE: SPDF: second WG review<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Dear Wes and SMWG,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I assume when you write about <i>
servicePackageType</i> you actually mean <i>servicePackageSatus</i> (otherwise I can’t find any mention of
<i>servicePackageType</i> in the current white book).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">We also said, that eventually the
<i>servicePackageStatus</i> should be rather called <i>servicePackageState</i>, which however would imply actually state machine behind. As we said, this won’t however be formalized for time being, therefore
<i>servicePackageStatus</i> could stay as it is.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Now to the main issue: I agree, in case the only states would be SCHEDULED and ALTERNATIVE there is no much sense in having something else than activeScenario flag. Here is to note, however, in case the scenarios
are not being used at all for specific case, than there is no other way of conveying the status (which is than apparently the only “SCHEDULED”). Here we come actually to my main question: are we than imply, that as soon the Service Package exists, it is immediately
SCHEDULED? This may be appealing for the simplicity, but it does not correspond to the real life right now. I think everybody has in their scheduling systems some notion of the state or status of the request or pass or service or whatever. And they are being
somehow “requested”, later on are “planned” and/or firmly “booked”, than are being “executed” to get finally “done”. Whatever we do in CCSDS (if it will be state machine or some other mechanism) we need (in my opinion) to reflect such states/statuses.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Getting back to the state machine a bit, the question (again) is, when the Service Package actually comes into life? I remember some discussion where we’ve said, the Service Package actually pops up already when
the request is being initially processed. This was the time, when we decided to work on the state machine (-ish) to exactly check how the Service Package actually behaves. Therefore (despite of future continuing work on that), I’d say we have currently 8 states/statuses:
CREATED, SCHEDULED, REJECTED, CANCELLED, ABORTED, ARCHIVED, EXECUTING and ALTERNATIVE. What eventually comes to my mind is to actually scratch the ALTERNATIVE status, because it is truly covered by
<i>ScenarioDetails</i> class and <i>activeScenario</i> parameter.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">And finally, because we need to support the user’s notion of
<b>pass/contact/service/schedule/request*</b> status, the same time however are not yet so far to provide consistent state machine model or automation services which would such model support,
<u>I’d vote for keeping the <i>servicePackageStatus</i> as optional parameter with data type set to string,</u> allowing in early implementation phases to bilaterally agree between user and provider how this field is being used.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph"><i><span style="font-size:9.0pt;color:#1F497D">*I intentionally use all these terms as synonyms, because the currently in the world used definitions are not clear, and being used randomly – users asking “what is the status of my
request” often expect to hear “it is scheduled” or “is being executed” – ergo unconsciously they actually ask for status of the service or, in our terms, Service Package.
<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Except that, I saw you changed the
<i>servicePkgStatus</i> into <i>servicePkgUsage</i>, which I think nicely now differentiates to the status itself. I like it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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">From:</span></b><span 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>Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] via SMWG<br>
<b>Sent:</b> Dienstag, 20. November 2018 19:04<br>
<b>To:</b> <a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a><br>
<b>Subject:</b> [Smwg] SPDF: second WG review<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello, as discussed in today’s meeting, there is an updated SPDF book ready for the 2<sup>nd</sup> working group review:<o:p></o:p></p>
<p class="MsoNormal"><a href="https://cwe.ccsds.org/css/_layouts/15/WopiFrame.aspx?sourcedoc=/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Package%20Data%20Formats/White%20Book/Drafts/ServicePackageSpecification%20902.4-w0.02.docx&action=default">https://cwe.ccsds.org/css/_layouts/15/WopiFrame.aspx?sourcedoc=/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Package%20Data%20Formats/White%20Book/Drafts/ServicePackageSpecification%20902.4-w0.02.docx&action=default</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">The question we discussed in the meeting is:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">-</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">Right now, we have both:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New";color:#1F497D">o</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">a servicePackageType that is OPTIONAL indicating the state machine status (which right now is just whether the package is primary/active/scheduled or an alternate)<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in"><span style="font-family:"Courier New";color:#1F497D">o</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">within the OPTIONAL ScenarioDetails, there is an activeScenario boolean that indicates the same thing<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">-</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">If we don’t have any additional state machine states that are conveyed, then the activeScenario is better placed because the distinction between scheduled vs alternative is only relevant when using scenarios, in which case
ScenarioDetails (and activeScenario) is present.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">-</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">I think the servicePackageType is only useful to retain if there are additional sub-states that it would indicate, but from what I could tell in the examples Marcin worked with the group, I wasn’t sure that we had any. Marcin
had some other states like ‘CREATED’, etc., that I think were internal, and wouldn’t be relevant to the message exchanges, if I understood correct.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">So, I think the options are:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">Get rid of servicePackageStatus. </span><span style="color:#ED7D31">(this did not seem to be preferred in the meeting, and there might be uses for conveying states in the future)</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">Define other states in the enumeration for servicePackageStatus, or leave it open to take some additional TBD states (e.g. by making it an xsd:string rather than an enumeration). </span><span style="color:#ED7D31">(this seems
slightly preferable at the moment?)</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#1F497D">
</span><span style="color:#1F497D">Leave it alone under the assumption that there will be more states we think of later that we want the servicePackageStatus to be able to convey and that we’ll add them to the enumeration at some point in the future?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Other than this, I will also update the XML schema file and post that as well.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
</div>
</body>
</html>