[Smwg] RID SSF-R2-2, regarding the 'status' parameter

[John Pietras]

CSSMWG colleagues -
For what it's worth, when I wrote the last draft (June 2016) of the Service Agreement and Configuration Profile book
(http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Service%20Agreement%20and%20Configuration%20Profile%20Book/ServiceAgreementAndConfigProfile-902.5-W-0.5-160626.zip )
It was based on the common Service Management Header (SrvMgtHeader) class *including* the 'status' parameter, which was at the time cast simply as String32, not an Enumeration type as it is in the current Simple Schedule book . The Service Agreement/Config Profile book constrained the string values to certain contents, but it did not redefine the base type (which is the issue in RID SSF-R2-2

The formulation of the 'status' parameter in this way - as a simple string type in the SrvMgtHeader base class in which the individual specifications would constrain the string contents to specific sets of strings - was the result of discussions that we had on the exact topic that is the source of RID SSF-R2-2: how to avoid multiple definitions of the same element type (parameter) in the same namespace. Those discussions and the resulting decision to treat the 'status' parameter that way seem to have been forgotten in the intervening year or so.

NOTE 1 - We also discussed an approach in which we would keep the status parameter as an enumerated value, but pre-determine all of the possible values that all of the future services *might* use so as to keep one definition of the type, but we concluded that that would counter the concept of "extensible".

NOTE 2 - We recognized that casting the 'status' parameter as a simple String type would require application-level validation (i.e., above XML validation), but that an enumerated-value 'status' that contained all possible values across all format books would still  require application-level validation to ensure that the value is correct for correct for the given format.

So if you want to keep things in the same namespace, I think that there are two possible solutions to the RID:

1.       Return to the previous approach, in which the (simple) String-typed 'status' parameter belongs to the base SrvMgtHeader class, and each data format specified the allowed string value(s) for that format.

2.       Adopt Marcin's solution of creating a format-specific enumerated-value status type that has a unique name.

And of course, creating separate namespaces (also as proposed by Marcin) would also solve this problem.

Best regards,
John


From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Tuesday, July 18, 2017 7:03 PM
To: CCSDS Service Mgmt WG
Subject: [Smwg] Preliminary RID dispositions uploaded

CSSM Colleagues,

Thank you to those of you who participated in the RID disposition session at today's teleconference. The dispositions that were recorded in the spreadsheet during our WebEx session have been uploaded to the CWE and may be retrieved via the link below.

For those not at the teleconference, the goal is to have the final dispositions by August 1st.

Best regards,
-Erik


https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private%20-%20Beta/Book%20Production/Blue/Schedule%20of%20Services/Red%20Book/Agency%20Review/Red-2/902.1-R-2-ConsolidatedRIDs-PrelimDispositions-18-July-2017.xlsx


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20170720/41f49786/attachment.html>