[Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
John Pietras
john.pietras at gst.com
Tue Nov 2 13:48:08 EST 2010
Yves,
I tend to agree with your choice of option 2. I can use it in the Service Control service, by setting directiveQualifier to null and extending the directiveIdentifier to be a complex type that includes directive names and context-specific values. (In effect, I'm using the idea of directiveQualifier but making its type and value linked to the specific directiveIdentifier value. I have to be able to do this because the directive IDs and their "qualifiers" have to be defined externally in a published control parameter list.)
Note that none of these three options support the statement made for the directiveQualifier for the EXECUTE-DIRECTIVE operation of the Throw Event procedure:
"It shall be possible to use the procedure as is (i.e., without extension) using the
parameters:
a) directive-identifier defined as an ASCII string;
b) directive-qualifier defined as a list of parameter name and parameter
values."
That will have to be changed to (OCTET STRING. (Also, should the default value for directive-identifier be OCTET STRING instead of ASCII string - that is, the derived service/prcedure would still have to refine it?)
Using this option, for the EXECUTE-DIRECTIVE operation of the Data Processing oepration, directiveIdentifier would be resolved as the extended choice and extended with a type that has the value 'reset', and directiveQualifier would be resolved as the extended choice extended as an integer value. This leads to some questions about what values derived versions of EXECUTE-DIRECTIVE can assign to directvieQualifier. The AbstractChoice type (I like your name better than my "AbstractType")has embedded in its definition that once a CHOICE is selected, all further derivations must follow that choice. That is, if the OCTET STRING choice is selected, the most any derived procedure/service can do is refine the contetn of that string. (If the exended value is chosen and the extension type is defined to have a choce of EMBEDDED PDV, then going down that branch still preserves a lot of flexibility.) The directiveQualifier, defined as AbstractChoice, is therefore subject tot his constraint.
On the other hand, it's not clear whether the directiveQualifier is intended to be constrained in the same way. That is, as currently defined in your option 2, there appears to be nothing to stop service XYZ from defining directiveQualifier as an OCTET STRING, and then have service XYZ' (derived from XYZ) define directiveQualifier as an extended type. Do we want to allow this behavior, or should the definition of directiveQualifier alwas be bound to its parent operation? (another example - if the parent operation sets it to NULL, can a child operation set it to some non-null value?)
However, it seems that it has to have the same type of constraint in order to make any sense. Using the Data Processing procedure example, a derived EXECUTE-DIRECTIVE could add another dirctiveIdentifier and associated diirectiveQualifier (unless prohibited by the Data Processing procedure, which it is not). But it would still have to support the 'reset' identfier and associated integer-valued qualifier. If the new identifier has its own qualifier, that qualifier has to extend the list - that is, be added to the integer value. So we need to put the right words into the specification.
Finally, in this new type definition and throughout the FW, we have instances of "extended" components of type "Extended" in some cases and "EMBEDDED PDV" in other cases. It would be nice if "embedded" were restricted to be of type "Embedded" to minimize confusion, and come up with a new name for components of type EMBEDDED PDV (e.g., "alternateType" or "newType"). I realize that this would ripple throught the ASN.1, but I do think that it would help readability.
Best regards,
John
-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Tuesday, November 02, 2010 11:42 AM
To: Ray, Timothy J. (GSFC-5830)
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear Tim,
Thanks for your reply.
The AbstractType is introduced for operations (TRANSFER-DATA, PROCESS-DATA and EXECUTE-DIRECTIVE) such that a procedure can use them without need for extension. If we add the NULL capability, this will allow users to send any of the three operations without data. In my view this would not make sense.
During the meeting, we agreed to the AbstractType as I have proposed it (See
NASA-JVP-16)
Reading it again last night I came to the conclusion that option 2 is my preferred one as it gives the capability to send an EXECUTE-DIRECTIVE with an identifier and set the qualifier to "null". This option gives the possibility we need and is cleaner.
Option 1 is less appropriate as it would enforce a requirement stating "in case the qualifier is not used, the service-provider shall send an empty string". I think this would not be adequate.
Best regards
Yves
From: "Ray, Timothy J. (GSFC-5830)" <timothy.j.ray at nasa.gov>
To: "Yves.Doat at esa.int" <Yves.Doat at esa.int>, "css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org>
Date: 02/11/2010 16:29
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear Yves,
I like option #1 because I can understand what is needed.
Do you think it might make sense to modify our AbstractType to add a third choice as follows? I’m thinking that this may not be the only situation in which the ‘user’ of AbstractType will want the option of ‘unused’.
AbstractType ::= CHOICE
{ unused
NULL
, opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
Or, create two classes of AbstractType as follows:
MandatoryAbstractType ::= CHOICE
{
opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
OptionalAbstractType ::= CHOICE
{ unused
NULL
, opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
Best regards,
Tim
From: css-csts-bounces at mailman.ccsds.org [ mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Monday, November 01, 2010 1:04 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear all,
I know you are all back in your daily work and quite busy so I will do my best to be short. My question is at the end of the mail.
I started to look at the EXECUTE-DIRECTIVE trying to answer the RID we discussed last week,
RID references: NASA-JVP-15. NASA-JVP-16.
Our requirements:
1. Enure a procedure and/or a service using the operation to have the
possibility to use the operation withour extension.
2. Reuse the AbstractType (proposed definition as follows):
-- This type is used by operations allowing the procedures
-- using them to two possibilities for the definition of the data:
-- 1. opaqueString: direct use. No extension required
-- 2. extendedData: definition of a complex type using a constructed
syntax
AbstractChoice ::= CHOICE
{ opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
3. Link the the directive qualifier to the directive identifier.
Possible redefinitions
Option 1:
Exec-Dir
Pro’s: - reuse AbstractChoice
- simple
- if dir-qual is not required we add a requirement to use an empty octet-string
Con’s: - mixture octet-string & extended is possible.
- does not link a given dir-qual to a given dir-id: dedicated requirement in the text can solve that.
- in case dir-qualif is not required, it cannot be mapped to a NULL value but to an empty Octet String.
ExecuteDirectiveInvocationOption1 ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier AbstractChoice
, directiveQualifier AbstractChoice --
qualifier of the directive identifier
, extensionParameter Extended
}
Option 2:
Exec-Dir same as option 1 but with a different dir-qualif definition
Pro’s: - reuse AbstractChoice
- simple
- if dir-qual is not required we add a requirement to use an empty octet-string
Con’s: - mixture octet-string & extended is possible.
- does not link a given dir-qual to a given dir-id: dedicated requirement in the text can solve that.
ExecuteDirectiveInvocationOption1 ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier AbstractChoice
, directiveQualifier CHOIDE -- qualifier of the
directive identifier
{ octetString [0] OCTET STRING
, null [1] NULL
, extended [2] EMBEDDED PDV
}
, extensionParameter Extended
}
Option 3:
Pro’s: - does not allows octet-string & extended mixture
Con’s: - more complex structure (but still workable)
- AbstractChoice not reused
- does not link a given dir-qual to a given dir-id. dedicated requirement in the text can solve that.
ExecuteDirectiveInvocationOption2 ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentification CHOICE
( octetString [0]
SEQUENCE
{ directiveIdentifier OCTET
STRING
, directiveQualifier CHOICE
{ selected [0]
OCTET STRING
, unused [1]
NULL
}
}
, Extended [1] SEQUENCE
{ directiveIdentifier EMBEDDED
PDV
, directiveQualifier CHOICE
{ selected [0]
EMBEDDED PDV
, unused [1]
NULL
}
}
, extensionParameter Extended
}
Notes:
- None of the options ensure a proper link between the identifier and he qualifier. We should be able to cover the link by appropriate requirements in the text
- Option 1 is the simplest but may require more requirements for a proper usage.
Could you please let me know from your opinion which option answers the best our discussions from last week.
1. Option 1?
2. Option 2?
3. Option 3?
4. New option?
Best regards
Yves
More information about the Css-csts
mailing list