[Css-csts] RE: directive-identifier and directive-qualifier
John Pietras
john.pietras at gst.com
Mon Apr 11 15:26:13 EDT 2011
Yves,
Having rested my mind from thinking about the
directive-identifier/directive-qualifier issues for a few months now,
I've taken a fresh look at the situation and have come up with an
approach that I think will work.
The Red-1 versions of the Throw Event and Data Processing procedures
(the two FW procedures that use the EXECUTE-DIRECTIVE operation)
represent two different concepts for how the values of the directives
are fixed. In the Throw Event procedure, the directives are normally
expected to be defined outside of the specifications of the services
that uses it, e.g., in a SANA-defined database or one that is specific
to the Complex that provides the service. This allows the set of
directives and their related qualifying data to be managed without
having to modify the specifications themselves. This is the way that the
FCLTU SLE service uses the THROW-EVENT operation, and the way that the
Service Control CSTS would use the Throw Event procedure.
On the other hand, there are cases where the procedure that uses the
EXECUTE-DIRECTIVE operation has one or more directives and associated
qualifying data that are integral to the execution of the service
itself. This is the case with the Data Processing procedure, where the
directive that is being "thrown" is a reset of the procedure itself, and
the qualifier of that directive is the identifier of the PROCESS-DATA
invocation that will be sent next.
I think that trying to define the base EXECUTE-DIRECTIVE operation so
that it explicitly supports both of these concepts has led us to an
overly-complicated syntax for that base operation. The core of the
proposed approach is to replace the two separate directive-identifier
and directive-qualifier parameters of the base EXECUTE-DIRECTIVE
operation with a single, purely abstract directive parameter. The purely
abstract parameter would be represented in the ASN.1 as being of type
Embedded, and it would different from the abstract choice type that
allows either an octet sting or Embedded value. This even-simpler
EXECUTE-DIRECTIVE provides just enough structure to define an operation
that can be further extended to meet the specific needs of the Throw
Event and Data Processing procedures of the Framework, and also be
extended by any service that needs to use the operation.
In the Throw Event procedure of CSTSFW Red-1, the directive-identifier
and directive-qualifier could be defined by a derived procedure, or the
procedure provided an "as-is" syntax in which the directive-identifier
is an ASCII string and the directive-qualifier is "defined as a list of
parameter name[s] and parameter values". With the proposed simpler
EXECUTE-DIRECTIVE operation, the same intent is accomplished by saying
that the directive parameter can either be defined by a derived
procedure or can take the form of an ASCII string-valued
directive-identifier and a list of [qualifier-name: qualifier value]
pairs.
Assuming that the qualifier values are of type TypeAndValue, the
extension syntax would look like
TeExecuteDirectiveInvocationDirectiveExt ::= CHOICE
{ idAndQualifierList [0] SEQUENCE
{ directiveIdentifier VisibleString
, directiveQualifier SEQUENCE OF
{ qualifierName VisibleString
, qualifierValue TypeAndValue
}
}
, extensionDirective [1] Embedded
}
NOTE 1 -In the above extension type definition, the extensionDirective
is of type Embedded, meaning that if it is chosen it must be given a
syntax: a NULL value (which would be allowed if the type were Extended)
is not a permissible value for the directive.
NOTE 2 - We might want to modify the type specification slightly to
allow a directive that simply has an identifier but no qualifiers. This
would be useful for directives that have no qualifiers
(arguments/parameters).
Now let's look at the Data Processing procedure. There, the procedure
adds a defined 'reset' directive which is accompanied by the identifier
of the next PROCESS-DATA invocation. To allow the possibility of derived
services adding other directives, the extension type can be defined as
follows:
DataProcessingExecDirectiveInvocationDirectiveExt ::= CHOICE
{ reset [0] NextProcessDataIdentifier
, extensionDirective [1] Embedded
}
NextProcessDataIdentifier ::= DataSequenceCounter
NOTE 3 -In the above extension type definition, the extensionDirective
is of type Embedded for the same reason as for the
TeExecuteDirectiveInvocationDirectiveExt type (see NOTE 1).
I look forward to your comments on this proposal.
Best regards,
John
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Sunday, December 12, 2010 1:29 PM
To: John Pietras
Subject: Re: directive-identifier and directive-qualifier
Dear John,
Your mail clearly demonstrates that the approach is too complex with too
many possibilities.
We have to find a simpler approach and we are back to square 1 (or 1.5).
What we need is a definition of the qualifier linked to the identifier
such as QualifierType defined by DirectiveIdentifier but this type of
definition is not obvious. I have to think about it and may be you will
find an idea as well. Let address this difficulty during the
teleconference.
Regarding your ASN.1 question your definition is correct if we want to
define without possible extension.
I will publish the RID disposition with one RID NASA-JVP-39, still open.
Best regards
Yves
From:
"John Pietras" <john.pietras at gst.com>
To:
<yves.doat at esa.int>
Cc:
<Margherita.di.Giulio at esa.int>, "Fred Brosi" <Fred.Brosi at gst.com>
Date:
06/12/2010 17:35
Subject:
directive-identifier and directive-qualifier
________________________________
Yves,
Thank you for the partially-updated draft CSTS FW that shows (among
other things) the changes that we discussed two weeks ago regarding the
directive-identifier and directive-qualifier. To recap the major points,
we came out of that telecon with:
a) directive-identifier defined as an ASCII string, the value (or
values) of which would be defined by the procedure that uses it; and
b) directive-qualifier defined as a choice of one of: an octet string,
null value (for when a qualifier is not needed), a list of {name:value}
pairs, or an embedded type.
This is represented within the ASN.1 ExecuteDirectiveInvocation as:
ExecuteDirectiveInvocation ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier VisibleString
, directiveQualifier CHOICE
{ octetString [0] OCTET STRING
, null [1] NULL
, parameterList [2] SEQUENCE OF
{ name PublishedName
, value TypeAndValue
}
, embedded [3] Embedded
}
, extensionParameter Extended
}
Thinking more about the directive-qualifier since our conversation, I
find myself not being completely clear on the conditions under which one
of these directive-qualifier choices is the best "choice", and what the
effects of the selecting a given choice has on future derivability. In
particular, if the embedded choice is selected, do all future derived
service have to extend the extension parameter of the type defined for
that embedded component? In the course of thinking about these things, I
think that I may have come up with a simpler approach, and I would like
your opinion on whether you think that it will work. I apologize for
reworking this material yet again, but I think that it is still too
ambiguous (at least to me). If you would like to discuss this by telecon
either later this week or next we can do that. Also, if you think that
it would be worth opening up this conversation to some or all of the
other members of the CSTSWG (e.g., Tim, who wrote the Data Processing
procedure, or Martin G.) I think that would be a good idea, too. I hope
that my illustration of the points that I find confusing, and my
possible simplifications, are understandable.
Here we go ---
Take, for example, the formulation of the directive-identifier and
directive-qualifier for the Data Processing procedure. Under the
approach that we have most-recently discussed, directive-identifier has
the value "reset" and directive-qualifier is defined as the embedded
choice with syntax
DataProcessingExecDirectiveInvocationDirectiveQualExt ::= CHOICE
{ reset [0] NextProcessDataIdentifier
, extensionDirectiveQual [1] Extended
}
NextProcessDataIdentifier ::= DataSequenceCounter
Now, let's assume that we want to create a service that uses a derived
Data Processing procedure (call it Radar Data Processing) that adds two
directives: "refresh", which has no qualifier; and "repoint", which has
two qualifier values "az" and "el", which have Real values.
Now if all further derivations of Data Processing are constrained to
extend that choice (i.e., via the extensionDirectiveQual choice of the
DataProcessingExecDirectiveInvocationDirectiveQualExt type, we would
have to define an extenison type
RadarDataProcessingExecDirectiveInvocationExtensionDirectiveQualExt
::= CHOICE
{ repoint [0] SEQUENCE
{ az REAL
, el REAL
}
, extensionDirectiveQual [1] Extended
}
In the above case:
a) when directive-identifier = "reset", directive-qualifier takes the
DataProcessingExecDirectiveInvocationDirectiveQualExt:reset value;
b) when directive-identifier = "refresh", directive-qualifier takes the
DataProcessingExecDirectiveInvocationDirectiveQualExt:extensionDirective
Qual:null value; and
c) when directive-identifier = "repoint", directive-qualifier takes the
DataProcessingExecDirectiveInvocationDirectiveQualExt:extensionDirective
Qual:
RadarDataProcessingExecDirectiveInvocationExtensionDirectiveQualExt:repo
int value.
However, if new valuescan use the "top level" choices of the
EXECUTE-DIRECTIVE of the Data Processing procedure, no new type would
have to be defined for the "repoint" value - it can be constructed as a
parameterList. And the null value for the "refresh" value could be the
top-level null. That is:
a) when directive-identifier = "reset", directive-qualifier takes the
DataProcessingExecDirectiveInvocationDirectiveQualExt:reset value (same
as the above case);
b) when directive-identifier = "refresh", directive-qualifier takes the
ExecuteDirectiveInvocation:directiveQualifier:null value; and
c) when directive-identifier = "repoint", directive-qualifier takes the
ExecuteDirectiveInvocation:directiveQualifier:parameterList value, where
parameterList is defined as having two components, the first with name =
"az" and value of type float, the second with name = "el" and value of
type float.
Of the two approaches, I like the second one better - it allows the
"native" capabilities of the directive-qualiier to be used, and
minimizes the need for creating new extension types. However, I don't
know if that is how anyone thnks that this might be used.
Taking this though a little further, it occurs to me that the
octetString and embedded choices of directiveQualifier are redundant
with the types that are available through the paramterList parameter. If
we were to simpify directiveQualiifer to be
directiveQualifier CHOICE
{ null [1] NULL
, parameterList [2] SEQUENCE OF
{ name PublishedName
, value TypeAndValue
}
}
then every qualifier of type OCTET STRING could be represented as a
parameterList with one entry, with the value component of type
octetString.
Since the TypeAndValue type has a valueExtension component of type
Extended, I believe that it would be possible to use this approach
whenever an extended directive-qualiifer needs to be defined. That is,
instead of using directiveQualifier:embedded to define an extended
directive-qualifier type, we could use
directiveQualifier:parameterList:value:valueExtension. Does this make
sense? Is there anything that can be done using
directiveQualifier:embedded that cannot be done by using
directiveQualifier:parameterList:value:valueExtension?
Finally, I have a question about ASN.1 and EMBEDDED PDVs. If the
extension type is a single type with now choice, can the extension type
simply be cast as that type? For example, consider the case of the
DataProcessingExecDirectiveInvocationDirectiveQualExt type, which is
currently defined in annex D2.11 as
DataProcessingExecDirectiveInvocationDirectiveQualExt ::= CHOICE
{ reset [0] NextProcessDataIdentifier
, extensionDirectiveQual [1] Extended
}
dpExecDirInvocDirectiveQualExt OBJECT IDENTIFIER ::=
{dpExtProcedureParam 5}
NextProcessDataIdentifier ::= DataSequenceCounter
If we wanted to define the extsion type as always being of type
NextProcessDataIdentifer, with no possibility of extension, woutd the
extension type symtax be
DataProcessingExecDirectiveInvocationDirectiveQualExt ::=
NextProcessDataIdentifier
dpExecDirInvocDirectiveQualExt OBJECT IDENTIFIER ::=
{dpExtProcedureParam 5}
NextProcessDataIdentifier ::= DataSequenceCounter
or even more directly
DataProcessingExecDirectiveInvocationDirectiveQualExt ::=
DataSequenceCounter
dpExecDirInvocDirectiveQualExt OBJECT IDENTIFIER ::=
{dpExtProcedureParam 5}
?
Please let me know how you would like to proceed in addressing these
issues.
Best regards,
John
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110411/55e4c8db/attachment.html
More information about the Css-csts
mailing list