[Css-csts] opaqueString value possible for Cyclic Report?
-further questions
Martin Götzelmann
martin.goetzelmann at vega.de
Wed Dec 2 13:26:58 EST 2009
Dear John,
I certainly did not intend to hold up completion of the guidelines - but you asked for comments ;-)
I feel it is completely OK that we consider generalisation of the description within the red book review process, but I do think it would be worth an attempt. What follows are a few thoughts which I would like to share with you now because I will have forgotten them when we revisit the subject later.
I have the feeling we should be able to discuss the issue without reference to the specific ASN.1 mechanism used if we refer only to the textual definition of the data parameter is section 3.9.2.4 in the FW. This section currently says:
3.9.2.4 data
3.9.2.4.1 The value of the data parameter is the data unit generated.
3.9.2.4.2 The data parameter shall be contained in an octet string or in an extension.
3.9.2.4.3 A procedure using this operation:
a) shall refine (i.e. specify) the format and the semantic of the octet string in the data parameter; or
b) shall extend the operation by defining the structure and the semantic of the extension field in the data parameter.
This is almost independent of the specific extension mechanism. Almost, because I think 3.9.2.4.3 b) should not refer to the "extension field in the data parameter"; if the specification language supports inheritance there might not be such an extension field. I would rather suggest something like "shall extend the operation by specification of the detailed structure (or syntax and encoding?) of the data to be transferred". (Maybe 3.9.2.4.2 should also better refer to "the format and the semantic of the data in the octet string"?)
Based on this definition we could maybe talk about the possibility to specify that a parameter be optionally transferred using an opaque data type or be specified by an extension of the parameter syntax.
I actually like your proposal for a generalised "superimposed parameter" type that could be used systematically for such purposes and suggest that we include it into the specification if there is still a chance. However this is of course specified as an ASN.1 type and I am not certain we really need it for a more generalised discussion.
In general I feel it might be useful to consider whether we should attempt to formulate the guidelines in an ASN.1 independent manner and have an appendix in which we specify how to deal with the ASN.1 specification in the FW. This would be in line with the approach we have taken for the FW itself. Of course this is for consideration in the Red Book review process - I am not suggesting rework anything now.
Kind Regards, Martin
________________________________
From: John Pietras [mailto:john.pietras at gst.com]
Sent: 01 December 2009 18:14
To: Martin Götzelmann
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] opaqueString value possible for Cyclic Report? -further questions
Martin,
Thanks for your comments. Please see my replies interleaved below.
Best regards,
John
________________________________
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Friday, November 27, 2009 5:44 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] opaqueString value possible for Cyclic Report? -further questions
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.
I agree with you in principle, and in fact I spent some bit of time (admittedly not a long time) trying to think how to generalize the statements as you suggest. A problem is that it involves creating a generalization that doesn’t appear in the Framework itself, and so it becomes difficult to talk about in the abstract. For example, the extendable choice of the data parameter of the TRANSFER-DATA/PROCESS-DATA operation is specific to a “data” parameter: extendedData. If a more generic name were used (e.g., extendedContent) then the whole thing could be cast as a general type, e.g. “SuperposedParameter” (where “superposed seems to work, given its mathematics and quantum physics meanings):
SuperposedParameter ::= CHOICE
{ opaqueString OCTET STRING
, extendedContent Extended
}
And the data parameters of TRANSFER-DATA and PROCESS-DATA could be of type SuperposedParameter, e.g.:
TransferDataInvocation ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, generationTime Time
, sequenceCounter IntPos
, data SuperposedParameter
, extensionParameter Extended
}
If the Framework laid down that foundation, the Guidelines could then discuss the “type” in general. But I’m reluctant to create that infrastructure in the Guidelines, especially since the Guidelines are now “only” Magenta.
Finally, if I tried to generalize the concept for the Guidelines, we would probably have to take some time to get it all straight. Pragmatically, with the upcoming holidays and other things that need my attention, I need to wrap up the next draft version of the Guidelines pretty quickly, especially since we have advertised a December completion date.
Therefore, I propose that for my next draft of the Guidelines, I will keep the discussion in terms of the data parameters of the TRANSFER-DATA and PROCESS-DATA operations. As a working group we can decide whether it is important enough to take the additional time to generalize the concept before releasing it for processing and review as a Red Book, or to address it as a combined Framework/Guidelines issue during the Agency reviews of the Red Books.
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.
Again, I agree in principle, but getting this all properly defined for a generalized case will take some time and thought. If we essentially ignore the possibility of a derived service creating its own instance of a superposed extension parameter for the near term and only address the concrete case of the data parameter as defined in the Framework, we can (temporarily) avoid having to deal with this.
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.
Agreed, I will address these points in the general requirements for extension and refinement of parameters.
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).
Actually, I had already come to that conclusion, and the current in-progress draft of the Guidelines specifies that the service specification explicitly prohibit further extension if that is the intent. If further extension is not explicitly prohibited, then the specification of the syntax and transfer syntax must include specification of the extension mechanism.
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.
Agreed. I will attempt to cover these concepts in the next version.
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.
That’s my understanding, too, but I don’t know if we can (or should) elevate it to a “shall”. I will add a NOTE stating that as the intention of the opaqueString choice, I can also add a “should” normative statement that says that if the service specification is itself the source of the specification of the syntax of the data parameter, then the Extended type should be used (actually, I think the extendedData choice should be of type EMBEDDED PDV, not Extended, but I’m addressing that in a separate email).
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
______________________________________________________________________
________________________________
______________________________________________________________________
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/20091202/eb30649c/attachment.html
More information about the Css-csts
mailing list