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

ID | Project | Category | View Status | Date Submitted | Last Update
0006736 | Part 01: TTCN-3 Core Language | New Feature | public | 22-04-2014 08:24 | 04-01-2015 19:53

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | major | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | Appendix B
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0006736: new matching mechanism for binary string types

Description

Lots of protocols carry payloads. This leads to complicated check(receive)->decvalue->match->receive constructions which we encounter more and more frequently.
Assuming, we have a type
type record R {
// ... headers
// ...
octetstring payload
}
and we want to receive an R carrying a payload whose decoded value matches a template t of type T.
This can, at the moment, be achieved by something like the following:
template T t := ...;
template R r := ...;
var octetstring payload;
var T decoded_payload;
alt{
[] p.check(receive(r)) -> value (payload := payload) {
if (decvalue(oct2bit(payload), decoded_payload) == 0) {
if (match(decoded_payload, t) {
p.receive;
}
}
}
We propose a new matching mechanism which can achieve the same in a much more convenient (and compositional manner, in case the payload again contains a payload).
The syntax of this new matching mechanism would be simply:
match(t)
where t is the template to be matched.
This matching mechanism would be usable for all octetstring or bitstring values/fields and would match if and only if the value can be decoded successfully to the type of template t and the decoded value matches template t.
In that case, the above code can be shortened to:
p.receive(modifies r := { payload := match(t) });
For even more convenience, assignment of the decoded field could be allowed to a variable of the same type as the matched template:
p.receive(modifies r := { payload := match(t) }) -> value (decoded_payload := payload);

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006697 | closed | Gyorgy Rethy | Missing functionality to check absence of an object
related to | 0006783 | closed | Gyorgy Rethy | Wrong syntax to save exception parameters

Attached Files

CR6736_v1.docx (80,093) 18-06-2014 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3055&type=bug
CR6736_v2.docx (83,724) 19-06-2014 08:10
http://oldforge.etsi.org/mantis/file_download.php?file_id=3056&type=bug
CR6736_v3.docx (87,440) 19-06-2014 15:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=3059&type=bug
CR6736_v4.docx (89,856) 19-06-2014 17:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3063&type=bug
CR6736_v5.docx (118,934) 06-10-2014 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3084&type=bug
CR6736_v6.docx (120,760) 09-10-2014 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3128&type=bug
CR6736_v7.docx (126,123) 07-11-2014 11:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=3184&type=bug

Issue History
Date Modified | Username | Field | Change
22-04-2014 08:24 | Jacob Wieland - Spirent | New Issue |
15-05-2014 14:08 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
15-05-2014 14:09 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
17-06-2014 11:35 | Gyorgy Rethy | Note Added: 0012100 |
17-06-2014 11:36 | Gyorgy Rethy | Assigned To | => Tomas Urban
17-06-2014 11:36 | Gyorgy Rethy | Status | new => assigned
17-06-2014 16:57 | Tomas Urban | Relationship added | related to 0006697
18-06-2014 13:31 | Tomas Urban | File Added: CR6673_v1.docx |
18-06-2014 13:40 | Tomas Urban | Note Added: 0012124 |
18-06-2014 13:40 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
18-06-2014 13:40 | Tomas Urban | Status | assigned => confirmed
18-06-2014 15:18 | Tomas Urban | File Deleted: CR6673_v1.docx |
18-06-2014 15:18 | Tomas Urban | File Added: CR6736_v1.docx |
18-06-2014 19:52 | Jacob Wieland - Spirent | Note Added: 0012134 |
18-06-2014 19:56 | Jacob Wieland - Spirent | Note Edited: 0012134 | bug_revision_view_page.php?bugnote_id=12134#r41
19-06-2014 08:10 | Tomas Urban | File Added: CR6736_v2.docx |
19-06-2014 08:12 | Tomas Urban | Note Added: 0012138 |
19-06-2014 15:35 | Gyorgy Rethy | File Added: CR6736_v3.docx |
19-06-2014 15:39 | Gyorgy Rethy | Note Added: 0012152 |
19-06-2014 15:39 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
19-06-2014 15:39 | Gyorgy Rethy | Status | confirmed => assigned
19-06-2014 15:40 | Gyorgy Rethy | Note Edited: 0012152 | bug_revision_view_page.php?bugnote_id=12152#r48
19-06-2014 16:57 | Tomas Urban | File Added: CR6736_v4.docx |
19-06-2014 17:00 | Tomas Urban | File Deleted: CR6736_v4.docx |
19-06-2014 17:00 | Tomas Urban | File Added: CR6736_v4.docx |
19-06-2014 17:01 | Tomas Urban | Note Added: 0012158 |
19-06-2014 17:01 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
19-06-2014 17:01 | Tomas Urban | Status | assigned => confirmed
20-06-2014 08:16 | Jacob Wieland - Spirent | Note Added: 0012169 |
20-06-2014 08:42 | Tomas Urban | Note Added: 0012171 |
20-06-2014 14:13 | Jacob Wieland - Spirent | Note Added: 0012189 |
06-10-2014 10:30 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
06-10-2014 10:30 | Gyorgy Rethy | Status | confirmed => assigned
06-10-2014 10:34 | Gyorgy Rethy | Note Added: 0012220 |
06-10-2014 14:36 | Tomas Urban | File Added: CR6736_v5.docx |
06-10-2014 14:42 | Tomas Urban | File Deleted: CR6736_v5.docx |
06-10-2014 14:43 | Tomas Urban | File Added: CR6736_v5.docx |
06-10-2014 14:44 | Tomas Urban | Note Added: 0012232 |
06-10-2014 14:44 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
06-10-2014 14:44 | Tomas Urban | Status | assigned => confirmed
06-10-2014 16:50 | Jacob Wieland - Spirent | Note Added: 0012240 |
08-10-2014 09:22 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
08-10-2014 09:23 | Gyorgy Rethy | Note Added: 0012267 |
08-10-2014 09:23 | Gyorgy Rethy | Note Edited: 0012267 | bug_revision_view_page.php?bugnote_id=12267#r75
08-10-2014 14:08 | Jens Grabowski | Note Added: 0012284 |
08-10-2014 14:09 | Jens Grabowski | Status | confirmed => resolved
08-10-2014 14:09 | Jens Grabowski | Resolution | open => fixed
08-10-2014 14:09 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
09-10-2014 12:16 | Axel Rennoch | Note Added: 0012317 |
09-10-2014 12:16 | Axel Rennoch | Status | resolved => feedback
09-10-2014 12:16 | Axel Rennoch | Resolution | fixed => reopened
09-10-2014 12:20 | Axel Rennoch | File Added: CR6736_v6.docx |
09-10-2014 12:21 | Axel Rennoch | Note Added: 0012318 |
09-10-2014 12:21 | Axel Rennoch | Status | feedback => assigned
09-10-2014 12:22 | Axel Rennoch | Note Added: 0012319 |
09-10-2014 12:22 | Axel Rennoch | Status | assigned => confirmed
09-10-2014 14:13 | Tomas Urban | Relationship added | related to 0006783
10-10-2014 11:52 | Thilo Lauer | Note Added: 0012360 |
10-10-2014 12:02 | Jacob Wieland - Spirent | Note Added: 0012362 |
10-10-2014 12:06 | Tomas Urban | Note Added: 0012363 |
10-10-2014 12:13 | Jacob Wieland - Spirent | Note Added: 0012364 |
10-10-2014 12:15 | Jacob Wieland - Spirent | Note Edited: 0012364 | bug_revision_view_page.php?bugnote_id=12364#r87
10-10-2014 13:46 | Jacob Wieland - Spirent | Note Added: 0012366 |
03-11-2014 10:23 | Gyorgy Rethy | Note Added: 0012371 |
03-11-2014 10:23 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
04-11-2014 11:46 | Tomas Urban | Note Added: 0012393 |
04-11-2014 12:00 | Jacob Wieland - Spirent | Note Added: 0012394 |
04-11-2014 16:24 | Tomas Urban | Note Added: 0012407 |
05-11-2014 08:47 | Tomas Urban | Note Added: 0012414 |
05-11-2014 08:47 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
07-11-2014 11:46 | Gyorgy Rethy | Note Added: 0012490 |
07-11-2014 11:48 | Gyorgy Rethy | File Added: CR6736_v7.docx |
07-11-2014 11:50 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
07-11-2014 12:29 | Tomas Urban | Note Added: 0012491 |
07-11-2014 12:29 | Tomas Urban | Status | confirmed => resolved
07-11-2014 12:29 | Tomas Urban | Fixed in Version | => v4.7.1 (published 2015-06)
07-11-2014 12:29 | Tomas Urban | Resolution | reopened => fixed
07-11-2014 12:30 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
07-11-2014 12:30 | Tomas Urban | Status | resolved => feedback
07-11-2014 12:30 | Tomas Urban | Resolution | fixed => reopened
07-11-2014 12:30 | Tomas Urban | Status | feedback => resolved
17-11-2014 13:51 | Jacob Wieland - Spirent | Note Added: 0012506 |
17-11-2014 13:51 | Jacob Wieland - Spirent | Status | resolved => feedback
17-11-2014 13:51 | Jacob Wieland - Spirent | Status | feedback => resolved
17-11-2014 13:51 | Jacob Wieland - Spirent | Resolution | reopened => fixed
04-01-2015 19:53 | Gyorgy Rethy | Note Added: 0012607 |
04-01-2015 19:53 | Gyorgy Rethy | Status | resolved => closed

Notes

(0012100)
Gyorgy Rethy
17-06-2014 11:35

STF discussion:
The feature itself is useful. Reusing the match operation with a different semantics is not supported. Instead the syntax like below could be used.
template R r:= {
headers :=....,
payload := @encoded (t)
}
template T t:= {....}
var T v_t;
function f() {
P.receive(r) -> value (v_t := @decoded(payload)); /*will match decoded r, decode the payload field and match the decoded payload field against t; decoded payload is stored*/

(0012124)
Tomas Urban
18-06-2014 13:40

Proposal uploaded. There's slight change in the syntax. The existing modifiers are typically used without parentheses enclosing the object being modified, so I decided to use the same coding style. I also added an optional encoding format parameter which is useful for decoding character strings:
template R r:= {
headers :=....,
bin_payload := @encoded t,
txt_payload := @encoded("UTF-8") t2
}
p.receive(r) -> value (v_bin := @decoded bin_payload, v_txt := @decoded("UTF8") txt_payload);
Please check.

(0012134)
Jacob Wieland - Spirent
18-06-2014 19:52 (edited on: 18-06-2014 19:56)

there is a typo: hextring (occurring at least twice)
Also,
( FieldOrTypeReference |
@decoded [ "(" Expression ")" ] FieldOrTypeReference [ "," ] )
can be shortened to
( [ @decoded [ "(" Expression ")" ] ] FieldOrTypeReference [ "," ] )
In B.1.2.9, the template to be matched is first called the "decoded template" but later on is referenced as the "decoding target". It should be called consistently the "decoding target".
Otherwise, I'm very happy with the proposal.

(0012138)
Tomas Urban
19-06-2014 08:12

Jacob, thank you for noticing these problems. I corrected the proposal accordingly.

(0012152)
Gyorgy Rethy
19-06-2014 15:39 (edited on: 19-06-2014 15:40)

Technically OK with me. Results of my review and our verbal discussions with Tomas during it are captured in CR6736_v3.docx. During the review - that was based on CR6736_v1.docx - CR6736_v2.docx has been uploaded. Tomas, pls. review my output document CR6736_v3.docx, and also merge the changes between CR6736_v1.docx and CR6736_v2.docx into it.

(0012158)
Tomas Urban
19-06-2014 17:01

I merged the documents and made several minor changes in the examples concerning the receive operation. Please check.

(0012169)
Jacob Wieland - Spirent
20-06-2014 08:16

Just to be thorough, isn't the @decoded access missing for procedure-based communication (param assignments)? Sure, it's not as likely that a parameter may contain an encoded payload, but it's not impossible either.

(0012171)
Tomas Urban
20-06-2014 08:42

It doesn't make much sence, because currently you cannot assign a parameter field, only the whole parameter.

(0012189)
Jacob Wieland - Spirent
20-06-2014 14:13

of course, even the whole parameter could be a payload

(0012220)
Gyorgy Rethy
06-10-2014 10:34

It sounds reasonable that a signature parameter and also a return value may also contain encoded data.

(0012232)
Tomas Urban
06-10-2014 14:44

Support for @decoded in procedure-based communication added to the proposal. Please check.

(0012240)
Jacob Wieland - Spirent
06-10-2014 16:50

Looks fine.

(0012267)
Gyorgy Rethy
08-10-2014 09:23

Jens, make final cross-check pls.

(0012284)
Jens Grabowski
08-10-2014 14:08

Ok for me

(0012317)
Axel Rennoch
09-10-2014 12:16

reopen to add correctioin/changes from CR6783

(0012318)
Axel Rennoch
09-10-2014 12:21

updated getreply syntax due to CR6783

(0012319)
Axel Rennoch
09-10-2014 12:22

updated after reopening due to CR6783 discussion/solution

(0012360)
Thilo Lauer
10-10-2014 11:52

TTCN-3 already contains anything you need to handle payloads as shown below.
Therefore we strongly oppose to the @encode/@decode modifier solution,
as it hides relevant issues from the TTCN-3 users (TTCN was originally designed to make issues obvious. This was one reason why TTCN does not has implicit type conversions e.g. when assigning an integer value to a float variable)
If you simply define an altstep e.g. matchPayload and a template e.g. t_payload you get anything you need! And a few lines of TTCN-3 code make it obvious for TTCN-3 users what is really happening!
What is the need to make TTCN-3 more and more complex by @modifiers ???
The modifiers @encode / @decode will add additional complexity to the runtime system of compilers and it will require some effort to explain it to normal TTCN-3 users.
This code does the task pretty well - and it makes it obvious to the TTCN-3 user, what is really done:
type record R {
// ... headers
// ...
octetstring payload
}
template T t := ...;
template R r := ...;
template R r_payload(T t):= {
// ... headers
// ...
payload:=bit2oct(encvalue(t));
}
altstep matchPayload(R r, inout T t) runs on MyMTC
{
var octetstring v_payload;
var T v_decoded_payload;
[] p.check(receive(r)) -> value (v_payload := r.payload) {
if (decvalue(oct2bit(v_payload), v_decoded_payload) == 0) {
if (match(v_decoded_payload, t) {
p.receive;
t:=v_decoded_payload;
}
}
}
// use, send direction
p.send(r_payload(t));
// use, receive direction
matchPayload(r,t);
alt {
[] matchPayload(r,t) {...}
}

(0012362)
Jacob Wieland - Spirent
10-10-2014 12:02

Forcing the user to write the same (obviously quite complicated) function over and over again for every type is a clear sign that the language is in need of a feature. This new feature shall be introduced here. Of course, as with any feature, no one is forcing any user to use it.
Additionally, your approach is not compositional as the the proposal is. (i.e. it cannot deal with multiple-envelope-layers in a simple,readable way as the proposed feature does).

(0012363)
Tomas Urban
10-10-2014 12:06

You forget to add repeat statement to your code:
...
if (match(v_decoded_payload, t) {
p.receive;
t:=v_decoded_payload;
} else {
repeat;
}
...
Now compare it to the proposed solution:
type record R {
// ... headers
// ...
octetstring payload
}
template T t := ...;
template R r := ...;
template R r_payload(T t):= {
// ... headers
// ...
payload := t ;
}
// use, send direction
p.send(r_payload(encvalue(t)));
// use, receive direction
p.receive(r_payload(@encoded t))
alt {
[] p.receive(r_payload(@encoded t)) {...}
}
We save a lot of code this way! Besides, I am quite sure that the proposed solution produced much more readable solution.
Your code also has a serious drawback. Activating the p.check branch terminates processing of the snapshot, meaning that the following branches and defaults of the alt statement cannot be processed at all. That means that you cannot match any other payload types within this alt. Our proposal doesn't suffer from this issue.

(0012364)
Jacob Wieland - Spirent
10-10-2014 12:13 (edited on: 10-10-2014 12:15)

small correction, it would need to be template R r_payload(template octetstring t) := ... and send(r_payload(bit2oct(encvalue(...)))

(0012366)
Jacob Wieland - Spirent
10-10-2014 13:46

Actually, in Thilos workaround-with-existing-features proposal, you would need to disable the guard of the check-branch before doing the repeat, as otherwise, for the next iteration the same code would be called and you would have an endless loop. the value of that guard would need to be added as an inout parameter to the altstep (and you would need one flag for each such altstep).
So, no, though it may be possible in a very complicated (and not quite as powerful and non-composable) way to do the same things in TTCN-3 already, it is in no way near usable or readable.

(0012371)
Gyorgy Rethy
03-11-2014 10:23

Please be the 'STF owner' of the issues, let we discuss it at the afternoon.

(0012393)
Tomas Urban
04-11-2014 11:46

Result of STF discussion:
We agree with Thilo that the current core language specification contains enough features to handle encoded payloads. The proposed solution doesn't impose any restrictions on these features and users can still use them in their code (if they don't want to learn new features or consider that the @encoded/@decoded mechanism hides something important).
We disagree with the statement that the proposed feature "hides relevant issues from the TTCN-3 users". Both the @encoded matching mechanism and the @decoded modifier occuring in redirect assignments are precisely specified and any user can check the specification to find out what exactly these modifiers do. In case our description is not precise enough or contains ambiguities, we would like to know where precisely they are in order to correct them.
We cannot accept the argument that "the modifiers @encode / @decode will add additional complexity to the runtime system of compilers and it will require some effort to explain it to normal TTCN-3 users". If we accepted it, we couldn't add any new features to the language specification, because any new addition suffer from this issue. Besides, the proposed addition to the specification only formalizes what was requested by TTCN-3 users. The author of the CR was not the only one who requested a feature simplifying handling of encoded payloads.
The main reason for the proposed change is code readability and execution efficiency. It can be demonstrated on a simple example. In this example, the testing code can receive two envelope messages (Envelope1, Envelope2) with different payloads (Payload1 and Payload2 in Envelope1, Payload3 and Payload4 in Envelope2). In order to make the example more realistic, it contains a default reacting to unknown messages and response timeout. The example contains a common part and two variants of the testing code: the first one using the proposed features and the second one using already existing features.
// Common part
module Common {
type record Envelope1 {
integer contentId,
octetstring payload
}
type record Envelope2 {
charstring contentId,
octetstring payload
}
type record Payload1 {}
type record Payload2 {}
type record Payload3 {}
type record Payload4 {}
template Payload1 m_payload1 := {}
template Payload2 m_payload2 := {}
template Payload3 m_payload3 := {}
template Payload4 m_payload4 := {}
type port P message {
in Envelope1, Envelope2
}
type component Comp {
port P p;
timer tc_maxWait := 10.0;
}
altstep a_default() runs on Comp {
[] tc_maxWait.timeout {
setverdict(fail, "No message");
mtc.stop;
}
[] p.receive {
setverdict(fail, "Unexpected message");
mtc.stop;
}
}
}
// Proposed solution
module ProposedSolution {
import from Common all;
template Envelope1 m_envelope1(integer p_contentId, template octetstring p_payload) {
contentId := p_contentId,
payload := p_payload
}
template Envelope2 m_envelope2(charstring p_contentId, template octetstring p_payload) {
contentId = p_contentId,
payload := p_payload
}
testcase TC_01() runs on Comp {
var Payload1 v_payload1;
var Payload2 v_payload2;
var Payload3 v_payload3;
var Payload4 v_payload4;
activate(a_default());
tc_maxWait.start;
alt {
[] p.receive(m_envelope1(1, @encoded(m_payload1))) -> value (v_payload1 := @decoded payload) { }
[] p.receive(m_envelope1(2, @encoded(m_payload2))) -> value (v_payload2 := @decoded payload) { }
[] p.receive(m_envelope2("msg3", @encoded(m_payload3))) -> value (v_payload3 := @decoded payload) { }
[] p.receive(m_envelope2("msg4", @encoded(m_payload4))) -> value (v_payload4 := @decoded payload) { }
}
}
}
// Current solution
module CurrentSolution {
import from Common all;
testcase TC_01() runs on Comp {
var Payload1 v_payload1;
var Payload2 v_payload2;
var Payload3 v_payload3;
var Payload4 v_payload4;
var octetstring v_encPayload;
var boolean v_guard := true;
var integer v_numContentId;
var charstring v_strContentId;
activate(a_default());
tc_maxWait.start;
alt {
[v_guard] p.check(receive(Envelope1:?)
-> value (v_numContentId := contentId, v_encPayload := payload)) {
var Payload1 v_decodedPayload1;
var Payload2 v_decodedPayload2;
var bitstring v_payloadBits := oct2bit(v_encPayload);
if (v_numContentId == 1 and decvalue(v_payloadBits, v_decodedPayload1) == 0) {
if (match(v_decodedPayload1, m_payload1)) {
p.receive;
v_payload1 := v_decodedPayload1;
v_guard := false;
}
} else if (v_numContentId == 2 and decvalue(v_payloadBits, v_decodedPayload2) == 0) {
if (match(v_decodedPayload2, m_payload2)) {
p.receive;
v_payload2 := v_decodedPayload2;
v_guard := false;
}
}
if (v_guard) {
v_guard := false;
repeat;
}
}
[v_guard] p.check(receive(Envelope2:?)
-> value (v_strContentId := contentId, v_encPayload := payload)) {
var Payload3 v_decodedPayload3;
var Payload4 v_decodedPayload4;
var bitstring v_payloadBits := oct2bit(v_encPayload);
if (v_strContentId == "msg3" and decvalue(v_payloadBits, v_decodedPayload3) == 0) {
if (match(v_decodedPayload3, m_payload3)) {
p.receive;
v_payload3 := v_decodedPayload3;
v_guard := false;
}
} else if (v_strContentId == "msg4" and decvalue(v_payloadBits, v_decodedPayload4) == 0) {
if (match(v_decodedPayload4, m_payload4)) {
p.receive;
v_payload2 := v_decodedPayload4;
v_guard := false;
}
}
if (v_guard) {
v_guard := false;
repeat;
}
}
}
}
}

(0012394)
Jacob Wieland - Spirent
04-11-2014 12:00

The long version does not work with only one guard flag. You need one guard per alternative.

(0012407)
Tomas Urban
04-11-2014 16:24

It depends on encoding. In this particular example I assumed that Envelope1 and Envelope2 have distinct encoding. Thus, if a message is succesfully decoded as Envelope1, it cannot be decoded as Envelope2 when repeat is called. However, I admit that in many cases you will need one guard per alternative.

(0012414)
Tomas Urban
05-11-2014 08:47

Technically there doesn't seem to be any problem in details anymore, but Thilo opposes the whole idea. As time is running out, we should decide if we include the proposed changes to the standard and risk that it won't pass the acceptance procedure or postpone it to the next year. I personally think we have enough arguments to decide in favour of the proposed solution.

(0012490)
Gyorgy Rethy
07-11-2014 11:46

As discussed with Tomas, a matching mechanism is more appropriate as a modifier, as in fact we are not modifying an existing matching but defining a new one. For the consistency the price will be a new keyword. Also the name has been changed - after long discussion - to decmatch. MatchingDecodedContent is the now name of the matching mechanism.
See updated resolution proposal in CR6736_v7.docx.
Please review.

(0012491)
Tomas Urban
07-11-2014 12:29

Proposal reviewed. The proposed changes are ready to be added to the next version of the core language specification. Note for Jacob: please check the text too if you have time.

(0012506)
Jacob Wieland - Spirent
17-11-2014 13:51

In principle, it's fine with me. I still don"t like the new keyword, but I can live with it.

(0012607)
Gyorgy Rethy
04-01-2015 19:53

Added to draft V4.6.3