Subject: [dtn] AMP comment on Literal vs Operator

From: Brian Sipos <[email-masked]>
Date: Mon, 4 Apr 2016 21:06:23 +0000

This is a comment against "draft-birrane-dtn-amp-02".

As currently defined and used in the various draft ADMs, I don't see a protocol-level difference between literals and operators. What I mean by this is that, other than the type ID of the values, the definition of literal and operator are both made by MID definition. Both take an optional list of typed parameters and have a resulting value type. In this sense, a true literal is just the same as a nullary operator (e.g. the "CurTS" operator of "draft-birrane-dtn-adm-agent-01" is really just a literal which changes value over time).

There is certainly value in separating these two classes of objects, so having a "literals" vs. "operators" tree in the ADM OID subtree. Literals can be thought of as 'static' or 'identity' operators (in the case of the "User ..." literals of adm-agent-01).

Does it make sense to simplify the AMP specification by eliminating the "literal" type and keeping the "operator" type. This should have absolutely no effect on ADM specificity or clarity as they will still use "literals" and "operators" OID subtrees to distinguish semantics. The protocol representation would just be the same between the two variations.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 6 Apr 2016 16:30:50 +0000

I am hesitant to combine literals and operators as it would somewhat confuse expression syntax and type-checking an expression prior to (or during) evaluation.

For example, an (infix) expression of :  LITERAL OP LITERAL is valid (for a binary op) whereas LITERAL LITERAL is clearly not a valid expression. However, OP OP OP becomes much harder to check.

Agreed that these could be distinguished via OID subtrees but a type flag makes the type checking much easier on a general-purpose evaluation engine on an AMP agent.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Monday, April 4, 2016 5:06 PM
To: [email-masked]
Subject: [dtn] AMP comment on Literal vs Operator

---

From: Brian Sipos <[email-masked]>
Date: Mon, 11 Apr 2016 14:34:22 +0000

If there is a genuine distinction between the two classes, then they need to be separate; I have just not seen any real distinction in either syntax (result type and parameter list/types) or semantics (both produce a single typed value at run time when used in an expression or report). In any case, the "OP OP OP" must be handled and determined as valid/invalid by constructing the expression tree and comparing results vs. parameters types. Again, I may be missing something but I don't see the distinction in what the expression evaluator must do to determine validity of (postfix) "LITERAL LITERAL OP" vs "OP OP OP" vs. "LITERAL OP LITERAL OP" or any other possible expression->tree conversion.

After I wrote the above, I'm going to correct myself. After re-reading AMP section 4.10 (Operator) I'm now realizing a distinction which was confused by the current spec wording. The literal type takes run-time evaluation options as MID *parameters*, while the operator type takes run-time options not as MID parameters but as *operands*. I think it would help clarify the situation to state this in Sec. 4.10 and especially to avoid the overloaded term "parameter" in this section. If an operator MID were to take parameters, it would not affect how it uses expression operands.

Sorry if the above stream-of-though is confusing. It is a mix of my initial confusion and slow realization.

________________________________
From: Birrane, Edward J. <[email-masked]>
Sent: Wednesday, April 6, 2016 12:30
To: Brian Sipos; [email-masked]
Subject: Re: AMP comment on Literal vs Operator

-Ed

---