[Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Yves.Doat at esa.int
Yves.Doat at esa.int
Tue Nov 2 10:41:40 EST 2010
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