[Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Yves.Doat at esa.int
Yves.Doat at esa.int
Wed Nov 3 07:17:46 EST 2010
Dear John,
1) We can extend the AbstractChoice to emcompass a VisbleString, e.g.
AbstractChoice ::= CHOICE
{ opaqueString [0] OCTET STRING
, text [1] VisibleString
, extendedData [2] EMBEDDED PDV
}
That definition would be more flexible to support the statement "It shall be
possible to use the procedure as is".
2) Link between identifier and qualifier values.
The link cannot be enforced by the syntax. i.e. the syntax does not prevent
to use of a value for the identifier and an incorrect value for the
qualifier. I do no see how to solve that.
We have to build the link by requirements, e.g.
The 'reset' identifier shall be used with a qualifier identifying the
data-sequence-counter.
The 'reset' identifier shall use a visible string format.
The data-sequence-counter shall be defined as an extension of the
parameter directiveQualifier of the EXECUTE-DIRECTIVE operation
supporting an integer.
3) Link between the identifier type and the qualifier type.
I don't think we want to force a link between the type of the identifier and
the type of the qualifier (e.g. if the identifier is of VisibleString type,
the qualifier may be extended for an integer).
4) Possible alternative syntax:
ExecuteDirectiveInvocation ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier AbstractChoice
, directiveQualifier CHOICE
{ octetString [0] OCTET STRING
, namedList [1] SEQUENCE OF
{ name PublishedName
, value TypeAndValue
}
, null [2] NULL
, extended [3] EMBEDDED PDV
}
, extensionParameter Extended
}
This syntax fulfil the requirement: use as is.
5) EMBEDDED PDV.
I agree with you and I will raise a RID to cover that comment: NASA-JVP-74.
We could further discuss and close that particular issue on the 16.11. Would
that be Ok for you?
If yes would anybody else be interested to join?
Best regards
Yves.
From: "John Pietras" <john.pietras at gst.com>
To: <Yves.Doat at esa.int>, "Ray, Timothy J. (GSFC-5830)" <timothy.j.ray at nasa.gov>
Cc: css-csts at mailman.ccsds.org
Date: 02/11/2010 19:45
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Sent by: css-csts-bounces at mailman.ccsds.org
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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list