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

ID | Project | Category | View Status | Date Submitted | Last Update
0005809 | Part 01: TTCN-3 Core Language | Clarification | public | 24-11-2010 12:49 | 17-07-2011 07:03

Reporter | Andrus Lehtmets |
Assigned To | Ina Schieferdecker |
Priority | high | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.2 (interim 2011) | Fixed in Version | v4.3.2 (interim 2011) |
Clause Reference(s) | CL chapter 15.11 Concatenating templates of string and list types and BNF
Source (company - Author) | Elvior

Summary | 0005809: CL chapter 15.11 Concatenating templates of string and list types is not supported by BNF
Description | CL chapter 15.11 Concatenating templates of string and list types is not supported by BNF. We propose to modify BNF so: 111. SingleValueOrAttrib ::= MatchingSymbol | SingleExpression | ( TemplateRefWithParList [ ExtendedFieldReference ] ) [ TemplateConcat ] NewRule. TemplateConcat ::= StringOp SingleValueOrAttrib [TemplateConcat ]
Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0005513 | closed | Ina Schieferdecker | resolution of CR5092 contains bogus examples for charstring

Attached Files

es_20187301v040205m_CR_5809.doc (92,160) 26-05-2011 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2506&type=bug
es_20187301v040205m_CR_5809_v2.doc (115,200) 30-06-2011 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2529&type=bug
es_20187301v040205m_CR_5809_v3.doc (103,936) 01-07-2011 11:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2544&type=bug
es_20187301v040205m_CR_5809_v4.doc (109,056) 17-07-2011 06:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=2558&type=bug

Issue History
Date Modified | Username | Field | Change
24-11-2010 12:49 | Andrus Lehtmets | New Issue |
24-11-2010 12:49 | Andrus Lehtmets | Clause Reference(s) | => CL chapter 15.11 Concatenating templates of string and list types and BNF
24-11-2010 12:49 | Andrus Lehtmets | Source (company - Author) | => Elvior
24-11-2010 16:43 | David Diaz (MTP) | Note Added: 0009804 |
25-11-2010 11:54 | David Diaz (MTP) | Note Added: 0009805 |
25-11-2010 14:54 | Jacob Wieland - Spirent | Note Added: 0009806 |
25-11-2010 16:05 | David Diaz (MTP) | Note Added: 0009807 |
29-11-2010 13:08 | Jacob Wieland - Spirent | Relationship added | related to 0005513
29-11-2010 13:09 | Jacob Wieland - Spirent | Note Added: 0009827 |
30-11-2010 10:52 | David Diaz (MTP) | Note Added: 0009837 |
03-12-2010 10:09 | Gyorgy Rethy | Target Version | => Edition 4.3.2 (interim)
24-05-2011 15:30 | Gyorgy Rethy | Note Added: 0010031 |
24-05-2011 15:30 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
24-05-2011 15:30 | Gyorgy Rethy | Status | new => assigned
24-05-2011 19:29 | Gyorgy Rethy | Priority | normal => high
25-05-2011 09:47 | Jacob Wieland - Spirent | Note Added: 0010044 |
26-05-2011 14:17 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR_5809.doc |
26-05-2011 14:23 | Jacob Wieland - Spirent | Note Added: 0010088 |
26-05-2011 15:29 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
27-05-2011 15:47 | Gyorgy Rethy | Note Added: 0010106 |
30-05-2011 13:30 | Jacob Wieland - Spirent | Note Added: 0010109 |
29-06-2011 18:01 | Gyorgy Rethy | File Added: es_20187301v040205m_CR_5809_v2.doc |
29-06-2011 18:18 | Gyorgy Rethy | Note Added: 0010149 |
29-06-2011 18:26 | Gyorgy Rethy | File Deleted: es_20187301v040205m_CR_5809_v2.doc |
29-06-2011 18:26 | Gyorgy Rethy | File Added: es_20187301v040205m_CR_5809_v2.doc |
29-06-2011 18:26 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
30-06-2011 08:48 | Gyorgy Rethy | File Deleted: es_20187301v040205m_CR_5809_v2.doc |
30-06-2011 08:48 | Gyorgy Rethy | File Added: es_20187301v040205m_CR_5809_v2.doc |
30-06-2011 09:34 | Jacob Wieland - Spirent | Note Added: 0010152 |
30-06-2011 16:31 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 11:02 | Jacob Wieland - Spirent | Note Added: 0010173 |
01-07-2011 11:09 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR_5809_v3.doc |
04-07-2011 14:51 | Gyorgy Rethy | Status | assigned => resolved
04-07-2011 14:51 | Gyorgy Rethy | Resolution | open => fixed
05-07-2011 14:38 | Gyorgy Rethy | Status | resolved => feedback
05-07-2011 14:38 | Gyorgy Rethy | Resolution | fixed => reopened
05-07-2011 14:39 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
05-07-2011 14:39 | Gyorgy Rethy | Status | feedback => resolved
05-07-2011 14:39 | Gyorgy Rethy | Resolution | reopened => fixed
05-07-2011 14:39 | Gyorgy Rethy | Fixed in Version | => Edition 4.3.2 (interim)
17-07-2011 06:19 | Ina Schieferdecker | Note Added: 0010224 |
17-07-2011 06:19 | Ina Schieferdecker | File Added: es_20187301v040205m_CR_5809_v4.doc |
17-07-2011 07:03 | Ina Schieferdecker | Status | resolved => closed

Notes

(0009804)
David Diaz (MTP)
24-11-2010 16:43

Dear Andrus,
I think the new rule could be described as:
TemplateConcat ::= StringOp SingleValueOrAttrib
because you have the TemplateConcat [optional] recursion through the updated SingleValueOrAttrib rule.
Anyway, I think this rule is not enough in order to provide full support to clause 15.11.
I would suggest to add the "Syntactical Structure", "Semantic Description" and "Restrictions" sections in order to clarify the operation usage.
Regards,
David (MTP)

(0009805)
David Diaz (MTP)
25-11-2010 11:54

We have some additional comments on this.
Reading the 15.11 clause, a "new" concept seems to be defined: "single template". What's this? What's the syntax supported in this kind of statement?
I mean that a deep analysis should be performed in order to know what is going to be supported for concatenating "single templates". Because going through the actual TemplateBody rule will lead to provide syntactic support to absolutely all TTCN-3 templates, including for instance the "ifpresent" keyword (we can not rely this check in the semantic side!) and, in addition to this, due to this rule:
53. StringLength ::= LengthKeyword "(" SingleConstExpression [".." UpperBound] ")"
we are also supporting the use of ranges when specifying length restrictions (and this is not supported according to 15.11 description).
In conclusion, we suggest to:
1- Clarify this standard clause through the "Syntactical Structure", "Semantic Description" and "Restrictions" sections (Mantis CR - http://t-ort.etsi.org/view.php?id=5809 [^])
2- To specify the BNF rules required for this new operation performed over "single templates" expressions, once the 15.11 has been fully defined.
Best regards,
David (MTP)

(0009806)
Jacob Wieland - Spirent
25-11-2010 14:54

I think this issue is already resolved by the CR 5513.

(0009807)
David Diaz (MTP)
25-11-2010 16:05

Dear Jacob,
Thanks a lot for providing this info!
After reviewing the proposed solution â€œCR5513_resolution v7.doc [^] (91,648 bytes) 22-07-2010 11:58â€, I think this issue is not fully resolved, as far as:
- It is still possible to specify length restrictions using ranges, despite the clause remains stating â€œ constrained to a fixed lengthâ€.
- Usage and restrictions on the outer template [ExtraMatchingAttributes] mechanisms, if any, should be described â€“ I agree this could be confusing to everybody â€“ not only the user. If no limitation is going to be provided on this, samples are welcome. Let me please insist on requesting for detailed information on this clause. I think it is complex enough to provide the â€œusualâ€ sections we can see all along the standard document (Syntactical Structure, Semantic Description and Restrictions)
Best regards,
David (MTP)

(0009827)
Jacob Wieland - Spirent
29-11-2010 13:09

I agree with your point 1 and have amended a note to CR5513 in that regard. But I don't know what restrictions in the ExtraMatchingAttributes you are talking about? Please provide an example of what you want restricted and why.

(0009837)
David Diaz (MTP)
30-11-2010 10:52

Hi Jacob,
I don't want to add any restriction to the outer matching attribute. I just ask for clarifications on the â€œusage (and restrictions, if any is going to be considered)â€ of the ExtraMatchingAttributes when concatenating templates.
Example:
The following statements are syntactically valid:
template charstring t_Mycharstring := "ABC" & * length(2) & "E?F" length(1..7); //is this valid?
template charstring t_Mycharstring := "ABC" & * length(2) length(1..7); //is this valid?
template charstring t_Mycharstring := "ABC" & * length(2) & "E?F" ifpresent; //this is not valid
template Mymessage MyTemplate:=
{ :
field2 := "ABC" & * length(2) & "E?F" ifpresent, //is this valid?
field3 := ? length(3) //according to the proposed BNF, which rule is being applied?
field4 := ? length(1..4)
:
}
Additionally, according to the proposed BNF, which rule is being applied for field3 and field4:
the ( AnyValue [ LengthMatch ] ) | from rule 4. MatchingSymbol
or the [ExtraMatchingAttributes] from rule 1. TemplateBody ?
I think the first one is being applied, so this issue should be considered in case of defining a different syntax when concatenating templates, because â€œExtraMatchingAttributesâ€ allows the usage of ranges, but this should not be the case when concatenating templates.
Regards,
David (MTP)

(0010031)
Gyorgy Rethy
24-05-2011 15:30

Check the comment.

(0010044)
Jacob Wieland - Spirent
25-05-2011 09:47

We should add a NOTE (not a restriction, as it is not really restricting anything), saying that if a concatenation expression in a TemplateBody ends with a AnyValue or AnyValueOrOmit followed by a length restriction, this is supposed to be the WildcardLengthMatch associated with the Wildcard. Other extra matching attributes apply to the whole expression in the TemplateBody.
Example:
template hexstring x := 'f00'H & ? length(0..3); // length(0..3) applies to ?
template hexstring x2 := 'f00'H & ? length(0..3) length(3..6) // length(0..3) applies to ?, length(3..6) applies to the whole expression.
template hexstring x3 := 'f00'H & ? length(0..1) & 'b*'H length(0..20) // length(0..20) applies to the whole expression.
To me this last example also seems kind of illogical, as the length restriction could as easily be interpreted (naively) to be applicable to 'b*'H, thereby confusing the user. Maybe we should allow WildcardLengthMatch also for other MatchingMechanisms that can be concatenated (and could have variable length).
This would lead to the situation that, if the user WANTS to restrict the length of the whole template that does not end with a particle with a length restriction, they would need to add a paranthesis around the concatenation before appending the ExtraMatchingAttributes length restriction.
If that is a scenario we could live with, then we should remove this confusing feature. It would be a backward compatible change in regard to the situation before concatenation of templates was allowed. But, it would not be backward compatible to 4.3.1.

(0010088)
Jacob Wieland - Spirent
26-05-2011 14:23

I've aligned the examples to the text (only specific values and (length restricted) wildcards and no OctetStringMatch etc. are allowed) in 15.11.
I've disallowed StringLength in ExtraMatchingAttributes when SimpleSpec in TemplateBody is a concatenation expression as the length of any concatenation is fix/known anyway (because of the fixed length of the WildcardLengthMatch) and thus an extra StringLength would be superfluous/redundant anyway.
This resolves the syntactical ambiguity as any length appearing at the end of a concatenation must then be WildcardLengthMatch.
I also allowed SingleExpression (with static semantics type integer) in WildcardLengthMatch instead of ConstantExpression as there is no such restriction to a constant in the main text and there is an example using a variable.

(0010106)
Gyorgy Rethy
27-05-2011 15:47

In case of binary strings why to disallow e.g. '*'B when ? is allowed (and ? is then transformed back to '*' in the resulted string)? They are equivalent, refering to exactly the same set of values (all values allowed by the type).
On the other hand, in the case
type bitstring MyBit5 length (5);
type bitstring MyBit;
template MyBit5 c_bit5 := ?;
template MyBit c_bit := '1'B & c_bit5 & '1'B;
//what is the resulted template:
// '1*1'B length(7) or '1*1'B ?

(0010109)
Jacob Wieland - Spirent
30-05-2011 13:30

> In case of binary strings why to disallow e.g. '*'B when ? is allowed (and ?
> is then transformed back to '*' in the resulted string)? They are equivalent,
> refering to exactly the same set of values (all values allowed by the type).
I don't know. The text forbids it. I didn't write the text. I just aligned the examples with the text.
> On the other hand, in the case
> type bitstring MyBit5 length (5);
> type bitstring MyBit;
> template MyBit5 c_bit5 := ?;
> template MyBit c_bit := '1'B & c_bit5 & '1'B;
> //what is the resulted template:
> // '1*1'B length(7) or '1*1'B ?
I don't think this is allowed by the text either, as I understood it, only specific values (i.e. string literals) and (possibly fixed-length-restricted) wildcards are allowed. I quote:
"The single templates of binary string and list types shall contain only the matching mechanisms specific values, AnyValue or AnyValueOrNone constrained to a fixed length, AnyElement, or AnyElementsOrNone possibly constrained with a length attribute for list types"

(0010149)
Gyorgy Rethy
29-06-2011 18:18

1) By the '*'B vs. ? question I just meant that the ext allows both but the example '*'B has been replaced by ?; by this is not essential.
2) Jacob wrote:
"template hexstring x3 := 'f00'H & ? length(0..1) & 'b*'H length(0..20) // length(0..20) applies to the whole expression.
To me this last example also seems kind of illogical, as the length restriction could as easily be interpreted (naively) to be applicable to 'b*'H, thereby confusing the user."
I totally agree, I'm sure, this will be very confusing for the user. So I propose to completely forbid ExtraMatchingAttribute after concatenation, i.e. if the user wants to restrict the length of anything produced by concatenation, ALWAYS force the use of parantheses, independent of what is being concatenated.
Pls. note, even the simple case
'f00'H & 'b'H length(0..2)
is ambiguous, as length(0..2) may be understood as applied to the whole concatenation (in which case will not match anything) or applied to 'b'H only (in which case will match 'f00b'H).
Pls. review changes in es_20187301v040205m_CR_5809_v2.doc

(0010152)
Jacob Wieland - Spirent
30-06-2011 09:34

> 1) By the '*'B vs. ? question I just meant that the ext allows both but the example '*'B has been replaced by ?; by this is not essential. You're right, I overlooked AnyElementsOrNone. So the special case '*'O length(X) is also allowed by the text. Otherwise, we seem to be in agreement on disallowing length constraint on a concatenation expression.

(0010173)
Jacob Wieland - Spirent
01-07-2011 11:02

Adding the optional "(" ")" in the BNF makes no sense as they are already included in SingleExpression SingleExpression =>* Primary => "(" SingleExpression ")"

(0010224)
Ina Schieferdecker
17-07-2011 06:19

Implemented with editorial changes, see v4