[Smwg] Response for AI 2018-0410-06

Thu Sep 20 17:45:34 UTC 2018

Wes,

I tend to agree with the removal of the external reference.  So far we have allowed for things like "additionalParameter" to be added at selected extension points for the various format definitions. I think we could treat this as something similar such that if somebody needed some "master" reference they could just simply do this via an additional parameter. I think just keeping this "simple" for now by removing the external reference is fine.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Barkley, Erik J (3970)
Sent: Thursday, September 20, 2018 10:39
To: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: [Smwg] Response for AI 2018-0410-06

Hi Wes,

I am re-sending this to the email distribution with a reference to the AI number in the subject – I think this will help for AI tracking purposes and discussion at the Berlin meetings.

CSSM Colleagues,

If you have any responses, please respond to this email/subject.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.]
Sent: Monday, September 17, 2018 13:02
To: Barkley, Erik J (3970) <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: Re: [Smwg] Teleconference notes, August 28th + updated action items

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:

CLASS externalXref
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
Parameter

Description

Data Type

Data Units

externalXrefID

Mandatory parameter.
This parameter is used to reference a request ID assigned by the user  when submitting the originating Service Package Request

xsd:string

n/a

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<mailto: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<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] Teleconference notes, August 28th + updated action items

CSSM Colleagues,

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.

Best regards,

-Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180920/a2f5af08/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 201215 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180920/a2f5af08/attachment.png>