[Smwg] SPDF: second WG review - now referencing the correct version - additional comments 2

Tue Jan 22 22:04:38 UTC 2019

CSSMWG colleagues ---
At last week's WG telecon, we discussed this issue more than we originally intended to do (given Wes's absence) but the discussion pointed to an approach that will resolve most or even all of the ambiguities that were confusing me (as described in my email below).

Here is a proposal for removing the problems/ambiguities that troubled me in my earlier email (below), but of course there may be valid variations on this proposal. Below includes not only modifications to the SPDF book but also to the Common Data Entities and Abstract Events books:

A.      Instead of defining the ModifiedParameter class, re-use the existing FrParameter class that is defined in the Service Management Common Data Entities (what I have dubbed reference [12b] since there are currently two references numbered 12). By being defined in [12b], the FrParameter class is already available for use by all other SM Info Entities, including SPDF. This would also eliminate the confusion caused by the different representations, i.e., a class that contains an instance of AbstractParameter *class* (FrParameter) vs. a class that has a parameter of AbstractParameter *data type* (ModifiedParameter). Accompanied by this substitution, reword the  definition in 3.1.17 of the SPDF book along the lines of:
3.1.17  FrParameter
3.1.17.1  The FrParameter class is used in the Service Package Data Format to specify the values of functional resource parameters that have been modified from their values as originally specified in the referenced Configuration Profile, e.g., because the Service Package Request included the value changes. The FrParameter class shall be present for each modified FR parameter in a Brief Service Package.
3.1.17.2  The FrParameter class is defined in reference [12b]. As used in the Service Package Data Format:

a.       The frNickname parameter contains the functional resource nickname (see the definition of the frNickname parameter of the FrParameter class in reference [12b]) of the FR instance that contains the parameter for which the value has been modified;

b.       The name parameter of the AbstractParameter component contains the classifier (see the definition of the name parameter of the FrParameter class in reference [12b]) of the parameter for which the value has been modified; and

c.       The value parameter of the AbstractParameter component contains the value (see the definition of the value parameter of the FrParameter class in reference [12b]) of the parameter for which the value has been modified, , where the data type of the containing AbstractParameter is the type of the named parameter.

JVP Notes: (a) I removed the "optional" wording because that implies that that PM can include them or not. They must be included in Brief Service Packages if any of the parameter values have been modified. (b) By re-using the FrParameter class, the definition of the data types of parameters is kicked back to the FrParameter class definition. The only clarification necessary here is any special interpretation in the context of the SPDF. E.g., for the SMURF Service Package Request, the parameters would be described in terms of the parameters that should have their Configuration Profile values overridden for the particular Service Package Request.

B.      Move the definition of the AbstractParameter class from the Abstract Events Definition book to the Service Management Common Data Entities book. It is obvious that the AbstractParameter class is being used for more than just abstract events, so it should be in the Common Data Entity book.

C.      Some suggested tightening up of the specification of the FrParameter class (3.5.2 of the Common Data Entities book:

1.       In 3.5.2.1: "The Functional Resource *instance* to which the value is to be assigned is specified by the Functional Resource Nickname (see reference [12])."

2.       Insert two paragraphs after 3.5.2.2:

a.       The name parameter of the AbstractParameter component contains the classifier (see reference [12]) of the functional resource parameter; and

b.       The value parameter of the AbstractParameter component contains the value of the parameter, where the data type of the containing AbstractParameter is the type of the named parameter (see reference 12).

D.      Reference 12 of the Common Data Entities book currently refers to "Functional Resource Tech Note (or wherever the function resource nickname concept is defined). Issue x CCSDS ???? (Technical Note), CCSDS nnn.n-??-n. Washington, D.C.: CCSDS, ???? 201n". Since the Tech Note is not yet on any publication track, perhaps it would be better to refer to the Service Agreement/Configuration Profile book. Certainly that book will have enough information to clarify the concepts of frNickname, classifiers, etc. (even if in turn it references a future normative version/subset of the Tech Note.)

Best regards,
John

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of John Pietras
Sent: Monday, January 14, 2019 5:47 PM
To: Marcin.Gnat at dlr.de; wesley.m.eddy at nasa.gov
Cc: smwg at mailman.ccsds.org
Subject: Re: [Smwg] SPDF: second WG review - now referencing the correct version - additional comments

CSSMWG colleagues,
I wanted to explore in a bit more detail the component parameters of the SPDF ModifiedParameter class before tomorrow's telecon. It turned out to be an interesting journey.

In the SPDF book, the ModifiedParameters class is defined as having two parameters:

-          frNickname, described as "The functional resource nickname, as defined in the service agreement (indicating the text classifiers of the functional resource type name and instance number)", with Data Type "xsd:string Values as defined in reference [12]".

-          parameter, described as "The parameter is represented using an AbstractParameter class that includes the name (text classifier) of the parameter, as well as the value to be used for the parameter", with Data Type "AbstractParameter  Contents defined in reference [12]".

I'll start with "reference [12]" of which there are two in the current draft of the SPDF: Service Agreement and Service Configuration which I'll call [12a] and Service Management Common Data Entities [12b].

So now let's look at the frNickname parameter. The reference in the description to "service agreement" would seem to point to the SA and CM book ([12a]), although the current draft of that book does not mention frNickname. Presumably it will when it is fleshed out, so making the Data Type point to [12a] makes ultimate sense. HOWEVER, the FrParameters class in [12b] ALSO includes an fRNickname *parameter*, but the definition is currently just a reference to "Functional Resource Tech Note (or wherever the function resource nickname concept is defined). Issue x CCSDS ???? (Technical Note), CCSDS nnn.n-??-n. Washington, D.C.: CCSDS, ???? 201n". That is, it's not (yet) a data *type* on its own; i.e., if we are going to declare it to be a common type, it should be FrNickname, which is itself of type xsd:string. The FrNickname XML *type* could then be defined in the Common Data Entities (since it would be used in multiple Info Entities) and the rules for defining the contents of those strings defined in the SA & CP book. My final comment (for now) on the frNickname parameter: since we are now defining the configuration profiles to be part of the service agreement, it is technically correct to say that values of the frNicknames are defined as part of the Service Agreement. However, the assignment of the values will be as part of the configuration profile components of those service agreements.

Now let's look at the parameter parameter, which is specified as an AbstractParameter, defined in "reference [12]". Again, the first reference [12] (SA&CP) currently says nothing about AbstractParameter, but the second ref 12 (Common Data Entities) *does* mention AbstractParameter, but only with respect to the FrParameter class, the only element of which is fRNickname. So the trail runs stops here as far as understating what the parameter parameter of the SPDF ModifiedParameter class is.

Interestingly enough, the only definition of the AbstractParameter class that I have been able to find is in the Abstract Even Definition book. But in that book it is defined as having only a single parameter, name. Thus the AbstractParameter class defined in the Abstract Even Definition book does not meet the definition of the AbstractParameter type needed by the parameter parameter of the SPDF ModifiedParameter class, which must contain not only the name of the parameter but also the value.

At this point I will simply say that that there are inconsistencies across the books that need to be fixed. Finally, I'd recommend renaming the parameter parameter of the SPDF SPDF ModifiedParameter class to something a bit more specific, like frParameter.

Best regards,
John

[cid:image001.jpg at 01D4A10C.FFC61C80]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190122/673afb0e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 43006 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190122/673afb0e/attachment-0001.jpg>