ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007435 | Part 01: TTCN-3 Core Language | New Feature | public | 03-05-2016 17:00 | 12-12-2016 16:48

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.8.1 (published 2016-07) |
Target Version | v4.9.1 (published 2017-05) | Fixed in Version | v4.9.1 (published 2017-05) |
Clause Reference(s) | 19.1, 22.2.2, 22.2.3, 22.3.2, 22.3.4, 22.3.6, A
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007435: @decoded modifier is not compositional enough

Description

In case that a decoded payload again contains a decoded payload (both matched with the decmatch construct), it should be possible to assign also the inner decoded value to a variable in the receive-statement.
As an inline syntax in the value-assignment notation, I could imagine two variants:
Variant 1:
v_inner := @decoded <outer_payload>.@decoded <inner_payload>
where <outer_payload> is the extended field reference of the payload field in the root type and <inner_payload> is the extended field reference of the payload field in the decoded outer payload type.
Variant 2:
v_inner := @decoded (@decoded <outer_payload>).<inner_payload>
Additionally, it should be possible to also use the @decoded syntax on the right-hand-side of an assignment:
v_inner := @decoded v_outer.<inner_payload>
Of course, here, the problem of multiple layers where the inner layer shall be accessed directly without having to assign the outer layer to a variable, also exists.

Steps To Reproduce |

Additional Information

I am afraid that it might not be as easy as it seems. At the moment, the type of the first payload is dependend on the target variable type. However, if we allow the intermediate level(s), their types are not known. Please check the following example:
):
type record PDU {
PduHeader header,
bitstring outerPayload
}
type record OuterPayload1 {
OuterPayloadHeader header,
bitstring innerPayload
}
type record InnerPayload1 {
InnerPayloadHeader header,
integer data1,
charstring data2
}
...
var template PDU vmw_pdu;
var InnerPayload1 v_inner;
... //vmw_pdu is initialized
p.receive(vmw_pdu) -> value (v_inner := @decoded outerPayload.@decoded innerPayload);
In the example, it seems that the intention is to decode @decoded outerPayload to a value of the OuterPayload1 type. However, the compiler has no type information at the compilation time and cannot perform static analysis of the composed @decoded statement. Runtime-resolved vmw_pdu template doesn't help in this case, at least not during static analysis.
It would be possible to allow strong typing of the @decoded modifier as follows:
p.receive(vmw_pdu) -> value (v_inner := @decoded:OuterPayload1 outerPayload.@decoded innerPayload);
In this case there would be no obstacle for having multilayer @decoded modifier in standalone assignment statements:
var template PDU vmw_pdu;
var PDU v_pdu;
var InnerPayload1 v_inner;
p.receive(vmw_pdu) -> value v_pdu;
v_inner := @decoded:OuterPayload1 v_pdu.outerPayload.@decoded innerPayload);
Is such a solution satisfactory?

Tags | No tags attached.
Relationships |
Attached Files | CR7435-1.docx (45,364) 21-07-2016 16:35 http://oldforge.etsi.org/mantis/file_download.php?file_id=3431&type=bug CR7435-2.docx (47,781) 22-07-2016 08:19 http://oldforge.etsi.org/mantis/file_download.php?file_id=3432&type=bug CR7435-3.docx (32,114) 29-08-2016 14:49 http://oldforge.etsi.org/mantis/file_download.php?file_id=3507&type=bug

Issue History
Date Modified | Username | Field | Change
03-05-2016 17:00 | Jacob Wieland - Spirent | New Issue |
18-07-2016 10:37 | Jens Grabowski | Assigned To | => Tomas Urban
18-07-2016 10:37 | Jens Grabowski | Status | new => assigned
19-07-2016 09:37 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
19-07-2016 09:37 | Tomas Urban | Additional Information Updated | bug_revision_view_page.php?rev_id=297#r297
19-07-2016 11:11 | Jacob Wieland - Spirent | Note Added: 0013987 |
19-07-2016 11:12 | Jacob Wieland - Spirent | Note Edited: 0013987 | bug_revision_view_page.php?bugnote_id=13987#r299
19-07-2016 11:14 | Jacob Wieland - Spirent | Note Edited: 0013987 | bug_revision_view_page.php?bugnote_id=13987#r300
19-07-2016 14:40 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
20-07-2016 14:52 | Jens Grabowski | Note Added: 0014010 |
20-07-2016 14:52 | Jens Grabowski | Assigned To | Tomas Urban => KristÃ³f Szabados
20-07-2016 21:40 | KristÃ³f Szabados | Note Added: 0014015 |
21-07-2016 10:13 | Tomas Urban | Note Added: 0014025 |
21-07-2016 14:24 | KristÃ³f Szabados | Note Added: 0014030 |
21-07-2016 14:24 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
21-07-2016 15:22 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
21-07-2016 15:23 | Tomas Urban | Assigned To | Jacob Wieland - Spirent => Tomas Urban
21-07-2016 16:35 | Tomas Urban | File Added: CR7435-1.docx |
21-07-2016 16:36 | Tomas Urban | Note Added: 0014032 |
21-07-2016 16:36 | Tomas Urban | Assigned To | Tomas Urban => KristÃ³f Szabados
21-07-2016 16:36 | Tomas Urban | Status | assigned => confirmed
22-07-2016 08:19 | Tomas Urban | File Added: CR7435-2.docx |
22-07-2016 08:20 | Tomas Urban | Note Added: 0014033 |
22-07-2016 10:35 | KristÃ³f Szabados | Note Added: 0014034 |
17-08-2016 11:26 | Jacob Wieland - Spirent | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:27 | Jacob Wieland - Spirent | Product Version | => v4.8.1 (published 2016-07)
17-08-2016 11:27 | Jacob Wieland - Spirent | Target Version | => v4.9.1 (published 2017-05)
29-08-2016 14:49 | KristÃ³f Szabados | File Added: CR7435-3.docx |
29-08-2016 14:50 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
29-08-2016 14:50 | KristÃ³f Szabados | Status | confirmed => assigned
29-08-2016 14:51 | KristÃ³f Szabados | Note Added: 0014194 |
30-08-2016 11:02 | Jacob Wieland - Spirent | Note Added: 0014198 |
14-11-2016 13:51 | Jens Grabowski | Status | assigned => confirmed
14-11-2016 13:52 | Jens Grabowski | Assigned To | Tomas Urban => Gyorgy Rethy
14-11-2016 13:52 | Jens Grabowski | Status | confirmed => assigned
14-11-2016 13:52 | Jens Grabowski | Status | assigned => resolved
14-11-2016 13:52 | Jens Grabowski | Resolution | open => fixed
12-12-2016 16:48 | Gyorgy Rethy | Note Added: 0014392 |
12-12-2016 16:48 | Gyorgy Rethy | Status | resolved => closed
12-12-2016 16:48 | Gyorgy Rethy | Fixed in Version | => v4.9.1 (published 2017-05)

Notes

(0013987)
Jacob Wieland - Spirent
19-07-2016 11:11 (edited on: 19-07-2016 11:14)

I think this syntax is a bit confusing (because the @decoded at the beginning refers to the last item in the whole chain).
Maybe we should switch to a pure @decoded-selector which would look a bit like an anytype usage:
<extended-field-ref>.@decoded.<toplevel-type-reference>
in the example this would be:
v_inner := @decoded outerPayload.@decoded.OuterPayload1.innerPayload
or, alternatively
v_inner := outerPayload.@decoded.OuterPayload1.innerPayload.@decoded.InnerPayload1
The latter expression is fully context-free and self-contained (if outerPayload is a variable) and could also be used in a type-less environment like a log (in a typed environment, it is redundant, so maybe would help in type-checking).
For less redundancy, the last type-selection could be optional if the type of the whole expression is known from the context (e.g. the type of the lhs), which would yield:
v_inner := outerPayload.@decoded.OuterPayload1.innerPayload.@decoded
When using the type-cast-syntax, I would propose to do it like this:
<type>:@decoded <ref>
which would yield in our example:
v_inner := @decoded (OuterPayload1:@decoded outerPayload).innerPayload
or as a context-free expression:
InnerPayload1:@decoded (OuterPayload1:@decoded outerPayload).innerPayload
I.e. the type-prefix must only be added if the type of the @decoded expression is not known from its context.

(0014010)
Jens Grabowski
20-07-2016 14:52

Agreement Jacob and Tomas:
<extended-field-ref>.@decoded.<toplevel-type-reference>
in the example this would be:
v_inner := @decoded outerPayload.@decoded.OuterPayload1.innerPayload
or, alternatively
v_inner := outerPayload.@decoded.OuterPayload1.innerPayload.@decoded.InnerPayload1
The latter expression is fully context-free and self-contained (if outerPayload is a variable) and could also be used in a type-less environment like a log (in a typed environment, it is redundant, so maybe would help in type-checking).
Check also for acceptance for short form:
v_inner := outerPayload.OuterPayload1.innerPayload.InnerPayload1
Assigned to Kristof for crosscheck within Ericsson.

(0014015)
KristÃ³f Szabados
20-07-2016 21:40

If I understand correctly the syntaxes with @decoded() would conflict with the current standard, according to which the parameter when present would need to describe the encoding format of the universal charstring field.
regarding the syntax the "type-cast" looks better to me, as it is much easier to see what belongs to where. 2-3 or more embedding with the . notation and users will need to group the expression into its parts on paper.
I don't think the type prefix must be denied if the type is known from the context. Tools could ignore it if they want, the users could use it to make the expression more intuitively readable, and it could be used as a form to make the intent more explicit.

(0014025)
Tomas Urban
21-07-2016 10:13

The casting syntax doesn't contain a conflict. I would contain two pair of parenthesis if used with encoding:
InnerPayload1:@decode("UTF-8") (OuterPayload1:@decode("UTF-8") outerPayload).innerPayload
For me, it is less readable than dot notation as two parts of the inner payload (InnerPayload1 type and innerPayload field) are separated. The distance will grow if the protocol contains more items.
In order to increase readability, we could introduce a different lexical symbol for the dot notation so that the user can see when decoding takes place from the syntax. Yesterday we discussed two possible symbols (: and ->) with Jacob, but they were rejected, because they already have different meaning in TTCN-3. One possible candidate would be tilde (~). Its common meaning is "approximately" or "similar to" which would quite well fit its intended meaning in TTCN-3. Another possibility would be a direction sign, e.g. => or >>. If a symbol different than dot is used, we could skip using the @decoded modifier at all and use just the short syntax. Please see the following examples:
v_inner := outerPayload~OuterPayload1.innerPayload~InnerPayload1
v_inner := outerPayload~("UTF-8")OuterPayload1.innerPayload~("UTF-8")InnerPayload1
v_inner := outerPayload=>OuterPayload1.innerPayload=>InnerPayload1
v_inner := outerPayload=>("UTF-8")OuterPayload1.innerPayload=>("UTF-8")InnerPayload1
v_inner := outerPayload>>OuterPayload1.innerPayload>>InnerPayload1
v_inner := outerPayload>>("UTF-8")OuterPayload1.innerPayload>>("UTF-8")InnerPayload1
Kristof mentioned a problem with extended type reference. This is a valid remark. However, exactly the same problem exists with the anytype where only top-level types can be referenced. I would keep this rule valid for the decoded field reference in case the STF decides for the extension of the dot notation rule.

(0014030)
KristÃ³f Szabados
21-07-2016 14:24

We had a discussion and decided to got with the syntax: " v_inner := outerPayload=>OuterPayload1.innerPayload=>InnerPayload1 v_inner := outerPayload=>("UTF-8")OuterPayload1.innerPayload=>("UTF-8")InnerPayload1 " Also the type reference must be restricted to pointing to a top-level type definition, otherwise it would be impossible to separate it from the proceeding field reference.

(0014032)
Tomas Urban
21-07-2016 16:36

Proposal uploaded. Please check.

(0014033)
Tomas Urban
22-07-2016 08:20

Minor modification in the proposal: terminals added to the table A.2

(0014034)
KristÃ³f Szabados
22-07-2016 10:35

ExtendedFieldReference is used in many locations.
For example right now these seem to be syntactically OK:
match(..,..) => type
valueof(..,..) => type
some_function(...) => type
variable := field1 => (type) => (type) => (type)
Wouldn't it be better to keep this separated from the generic reference, somewhat like this?:
338.SingleValueSpec ::= VariableRef [AssignmentChar [( DecodedModifier ["(" Expression] ")"]
| DecodingOperation )] FieldReference ExtendedFieldReference]
??. DecodedOperation ::= {FieldReference "=>" DecodedFieldType}+
??. DecodedFieldType ::= PredefinedType | Identifier | "(" Type [ "," Expression ] ")"
---
shouldn't VariableAssignment be also updated for syntactic consistency?

(0014194)
KristÃ³f Szabados
29-08-2016 14:51

I have uploaded a new version with minor typo corrections. Please check/modifiy and assign to György (rapporteur)

(0014198)
Jacob Wieland - Spirent
30-08-2016 11:02

looks good to me

(0014392)
Gyorgy Rethy
12-12-2016 16:48

Added to V4.8.2