[Css-csts] opaqueString value possible for Cyclic Report? -further questions

Fri Nov 27 05:44:07 EST 2009

Dear John,

I concur with your description which I feel captures the essential rules for inheritance in presence of a choice between an opaque type and a "real" extension point. I also concur that these rules should be stated in the guidelines and for that I have a few thoughts for your consideration:

a) I feel the formulation of the rules should not specifically refer to the data parameter but rather address the case where the base procedure / operation includes the option to either use an opaque data type or a real extension mechanism. My justification for this proposal is that a similar approach may be taken by a service specification or for some other type in a later version of the FW. The data parameter should be discussed as an example.

b) If recommendation a) is followed we need to consider that the "real extension mechanism" depends on the syntax and notation used and therefore the general rule should not refer to ASN.1 specific constructs. How to apply the rule to the specific ASN.1 should of course be explained. This could be done in a note - or maybe better in a specific appendix explaining how to apply the guidelines to the ASN.1 specifications.

c) I feel that your point 3 applies to inheritance (extensions / refinement) in general and not only to the special case where a choice can be made between refinement of a opaque data type and a real extension and should therefore be specified when discussing extension / refinement in general. In the context of the specific topic, one could then refer to that specification for point 3. 

d) Your remark "the child service may only further extend the definition of that parameter, and only if the specification of the parent service’s syntax for that data parameter has extension capabilities" is of course completely correct, but may be obvious only for the specific ASN.1 approach we have selected. If we would be using java or (CORBA) IDL, for instance an interface could always be derived from (unless marked as "final" in Java). In a syntax/notation independent manner we might have to say that the parent procedure / operation / service has "disabled extension". Having said that, I wonder whether we should require that a specification must explicitly state that a type shall not be extended (or refined?) when this is intended (and no extension mechanism is supplied in the ASN.1 case).

e) Use of an opaque type is a sort of "poor man's extension mechanism" and therefore abstract inheritance rules for extension apply here as well - albeit in a different form. Maybe it would be useful to spell this out, stating that the basic principle is that you can add to the inheritance but you cannot remove anything and that you can refine but not replace or change - I am sure you can find better words.

f) Opaque data types present a very weak extension / refinement mechanism and extensive use of this approach could jeopardise the overall concept of the CSTS Specification Framework. Maybe it would be worth explaining for what purposes this approach can be considered and to state that it is discouraged for any other case. In my understanding use of an opaque data type makes sense when the data structure is defined in some other standard/specification and the CSTS does not need to look into the data but just passes them through - as this is done for a telemetry frame in RAF for instance.

Kind Regards,
Martin

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 25 November 2009 20:47
To: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] opaqueString value possible for Cyclic Report? -further questions

CSTSWG colleagues ---

Last Friday I sent the message below, which raised my concern about the possibility of the intended syntax of the data parameter not being enforced. I have come up with a few more questions regarding this parameter, especially with regard to how the type of the parameter might evolve through successive generations of services being derived. 

The following set of assertions comprise what I *think* the rules regarding the data parameter are, but I am not sure if anyone else agrees. I am eager to hear your comments.

1.	For a service that is composed of procedures that are adopted, derived, or constructed from Framework procedures and/or operations, the service must either specify that the data parameter is octet-string-valued and refine its definition (e.g., formatted as a CCSDS Transfer Frame) or specify it as an extended type and specify the syntax, transfer syntax, and syntax identifier. The NULL choice for the Extended type is not permitted. 
2.	For a service that is derived from a (parent) CSTS for the data parameter is defined as an octet-string, the child service may only further refine the definition of that octet string. The parent definition of the refinement must still be applicable. For example, a data parameter refined as “The name of a city” can be further refined as “The name of a city in North America”, but it cannot be refined as “The name of an automobile”. 
3.	For a service that is derived from a (parent) CSTS for the data parameter is defined as an Extended type, the child service may only further extend the definition of that parameter, and only if the specification of the parent service’s syntax for that data parameter has extension capabilities. The parent definition of the extension must still be applicable. For example, consider a parent service in which the data parameter of an operation is extended to make it vector-valued, where each element of the vector is defined as a sequence of an integer value and an extended parameter that may take a null value. A child service of that parent may extend the elements, but it cannot go back to an earlier extension point (that is, one that was exposed to the parent or another ancestor). 

Is this consistent with everyone’s understanding? I think that this needs to be addressed in the Guidelines, so the sooner we can confirm this (or correct it) the sooner I can finish the next draft of the Guidelines.

Best regards,

John

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Friday, November 20, 2009 4:03 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] opaqueString value possible for Cyclic Report?

CSTSWG colleagues ---

I hope that I am merely misunderstanding something, but it just now seems possible to me for the data parameter of the TRANSFER-DATA operation of the Cyclic Report procedure to have an octet-string value (via the opaqueString choice), even though our intention is that it have the QualifiedParameters syntax. That is to say, the ASN.1 CyclicReportTransferDataExt extension type extends the possible values to include the qualifiedParameter choice but it does not inhibit the opaqueString choice. 

Is my interpretation correct? If so, is the following statement in section 4.7.3.2 in the main text:

“The TRANSFER-DATA shall be refined as required in ‎3.9 to carry the selected parameters (names, type, value and qualifier) using the qualified-parameters parameter (see annex ‎B).”

sufficient to ensure that an implementation of the Cyclic Report procedure will not encode the data parameter as an octet string?

I realize that the book has already gone to the Secretariat for preparation as a Red Book. If there is a problem here, we would have to deal with it in the RID process.

Best regards,

John

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20091127/895d353e/attachment-0001.htm