[Smwg] Teleconference notes, August 28th + updated action items
Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.]
wesley.m.eddy at nasa.gov
Mon Sep 17 20:02:05 UTC 2018
On the AI 2018-0410-06 assigned to me, I have a proposed solution.
The action is: Check external reference definition and recommend a modification or deletion for the Service Package book
This is related to a section of the Service Package draft that was a little confusing for me. We had basically what looked like a rather generic structure for an external reference, which apparently was only needed optionally sometimes to contain a string that would link the service package to a corresponding request. The entire section in question is:
The externalXref class is optional and shall constitute optional reference information provided by the user mission in the originating Service Package Request.
There shall be at most one instances of the externalXref class for each instance of the ServicePackageResults class.
Table 3‑4 specifies the parameters defined for the externalXref class.
Table 3‑4: Class ExternalXref Parameters
This parameter is used to reference a request ID assigned by the user when submitting the originating Service Package Request
The diagram below shows how this relates to the ServicePackageResults (it’s near the top right):
[/Users/jchamoun/Desktop/Screen Shot 2017-05-11 at 2.14.43 PM.png]
However, the ServicePackageResults already contains a serviceReqID (which is unfortunately “serviceReqXref” in diagram above).
There was a discussion that this additional reference could be needed in case the original request is some flavor of standing order that generates multiple child requests over time, in which case one of these references would be to the parent request, and the other to the specific child that the package corresponds to.
The discussion then seemed to indicate that we might agree that a reasonable database design would be able to link the child request to its parent, so there might not be a need to indicate the parent here, since it could just be looked up separately in whatever application may need it.
My proposed solution is to just remove this, since it does not seem to be needed.
If for some reason, we need to have it, it would be cleaner to add an optional component to the ServicePackageResults that holds a parent request ID string, and can have a more natural name like parentServiceReqID.
We could explain them as:
- serviceReqID – mandatory indicating the specific service request that this package corresponds to
- parentServiceReqID – optional, in the case where a parent request generates multiple children, this field indicates the parent request, while the serviceReqID indicates the specific child corresponding to this service package.
But, my favored approach is to remove this.
Thoughts or feedback would be appreciated.
From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Barkley, Erik J (3970)
Sent: Tuesday, August 28, 2018 4:06 PM
To: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: [Smwg] Teleconference notes, August 28th + updated action items
Attached are the notes from the teleconference on August 28th. Corrections appreciated. The notes have also been uploaded to the teleconference folder on CWE (meeting materials --> 2018 --> Telecons or https://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DSM%2FMeeting%20Materials%2F2018%2FTelecons&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB&View=%7BD853EDDB%2DF007%2D4BF6%2D8C31%2DBA03A9D0F4A4%7D )
Also attached is the updated action item list which has also been posted to the action item folder in the CWE private space.
Our next telecon is scheduled for September 20th. Note that this replaces the telecom originally scheduled for September 25th.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 201215 bytes
More information about the SMWG