| |
ETSI's Bug Tracker |
| Anonymous | Login | Signup for local Mantis account | 02-05-2024 20:30 IST |  |
| Main | My View | View Issues | Change Log | Roadmap | Monitor project |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0005262 | Part 01: TTCN-3 Core Language | New Feature | public | 01-07-2009 14:51 | 30-11-2011 09:33 | ||||
| Reporter | Gyorgy Rethy | ||||||||
| Assigned To | Ina Schieferdecker | ||||||||
| Priority | normal | Severity | major | Reproducibility | have not tried | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | v4.1.1 (published 2009-06) | ||||||||
| Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.4.1 (published 2012-04) | ||||||
| Summary | 0005262: Partially constrained structured types | ||||||||
| Description | Today the standard allowes restricting structured types by a value list notation. This means that all the allowed concrete values shall be listed. Especially in case of record/set types with several fields it is not desired and not possible in practice. In these cases very often the need is just to limit the content of 1-2 fields. This could be easily achieved in the language if - borrowing the semantics of modified teplate bodies - the fields not listed in the values (of the subtype list) are considered not further restricted (i.e. any previous restriction is just inherited. Example: type record MyRec { integer int (0..255), charstring uname, charstring pswd } type MyRec MyRecRestricted ({uname := "rethy", pswd := "xyz"},{uname := "gyorgy", pswd := "zyx"}) The type MyRecRestricted allows records with field int containing an integer between 0 and 255 and with the combined content of the string fields uname and pswd {rethy,xyz} and {gyorgy,zyx} only. Pls. note, that this extension would allow to put logical constraints on combinations of record/set fields that would be a powerfull mechanism in case of several real-life propotocols. This extension would also allow to transform ASN.1 table constraints that are ignored today. | ||||||||
| Tags | No tags attached. | ||||||||
| Clause Reference(s) | new 6.2.13 | ||||||||
| Source (company - Author) | L.M.Ericsson | ||||||||
| Attached Files |  CR5262_resolution_v1.doc [^] (119,808 bytes) 27-09-2011 18:08 | ||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
|
(0009125) Ina Schieferdecker (reporter) 09-12-2009 15:42 |
A proposal has to be developed first - hence postponed to 2010. |
|
(0009270) Jacob Wieland - Spirent (reporter) 23-03-2010 19:03 |
Proposal: allow templates also in SubtypeSpec The BNF needs to be changed in the following way: 49 SubTypeSpec ::= AllowedValues [StringLength] | StringLength /* STATIC SEMANTICS - AllowedValues shall be of the same type as the field being subtyped */ 50 AllowedValues ::= "(" (ValueOrRange {"," ValueOrRange}) | CharStringMatch ")" 51 ValueOrRange ::= RangeDef | ConstantExpression | Type to 49 SubTypeSpec ::= AllowedValuesSpec [StringLength] | StringLength /* STATIC SEMANTICS - AllowedValuesSpec shall be of the same type as the field being subtyped */ 50 AllowedValuesSpec ::= "(" (TemplateOrRange {"," TemplateOrRange}) | CharStringMatch ")" 51 TemplateOrRange ::= RangeDef | TemplateBody | Type Also, the text of 6.1.2.1 needs to be changed accordingly: 6.1.2.1 Template List subtyping TTCN-3 permits the specification of a list of distinguished templates as listed in table 3. The templates in the list shall be valid templates for the type being constrained and the set of values matching at least one of these templates shall be a subset of the values defined by the type being constrained. The subtype defined by this list restricts the allowed values of the subtype to those values matched by the templates in the list. The templates in the list shall only (directly or indirectly) reference other templates or constant expressions. Constants used in the template expressions shall meet with the restrictions in clause 10. 6.2.13.2 List subtyping of structured types and anytype List subtyping is possible when defining a new type based on an existing parent type, but not directly at the declaration of the first parent type (see table 3). Subtypes defined by a list subtyping restrict the allowed values of the subtype to the values matched by the templates in the list. In case of list subtyping of record, set, record of, set of, union and anytype types, the list may contain both templates and subtypes of the parent types of the type being constrained. The collection of templates denoted by the type(s) referenced in the list become instances of the new subtype. All expressions of the expanded list (i.e. after resolving the type references) shall be valid template expressions of the first parent type. The templates in the list shall only (directly or indirectly) reference other templates or constant expressions. Constants used in the template expressions shall meet with the restrictions in clause 10. Generally, all references to 'value list' in regard to the matching mechanism or subtyping should be replaced in the whole text by the more appropriate term 'template list' so it cannot be confused with the frequently used term 'value list notation'. Also, the 'value list' matching mechanism is already explicitely allowed to contain template expressions which is all the more reason to rename it properly. |
|
(0009663) Jacob Wieland - Spirent (reporter) 31-08-2010 11:45 |
The changes I have proposed would allow the example given in the CR to be valid. In case of real-life protocols with lots of fields where only a few fields should be restricted, the following approach could be taken: given the following definition: type record PDU { T1 f1, ... Tn fn } we would add these definitions: template PDU basePDU := ?; template PDU restrict(T1 f1 := -, ... Tn fn := -) modifies basePDU := { f1 := f1, ... fn := fn } Then, we could define our restricted type(s) like this: type PDU RestrictedPDU ( restrict(...), // give the fields that should be restricted as parameters restrict(...), restrict(...), ... restrict(...) ); If you don't want the additional generic template, you could also use inline templates: type PDU RestrictedPDU ( modifies basePDU := { ... }, modifies basePDU := { ... }, ... modifies basePDU := { ... } ) Of course, if these ways are seen as too clumsy, we could additionally define that in SubtypeSpec, all (implicitly) omitted fields are automatically ? or * for optional fields, yielding the same result. |
|
(0009682) Jacob Wieland - Spirent (reporter) 01-09-2010 17:05 |
please review |
|
(0009705) Gyorgy Rethy (reporter) 03-09-2010 10:17 edited on: 03-09-2010 10:17 |
STF discussion and agreement on 01-09: - Subtype constraint shall allow templates, resolvable at compile time (e.g. parameterzized templates shall be called with literal values and constains resolvable at comile time only) - Allow partial definition of subtype constraints - Fields missing in the subtype constraints are automatically and implicitly gets with ? and * constraint E.g. the following both will be legal (but have different semantical meaning): type MyRec MyRecRestricted ({uname := "rethy", pswd := "xyz"},{uname := "gyorgy", pswd := "zyx"}) type MyRec MyRecRestricted ({uname := ("rethy","gyorgy"), pswd := ("xyz","zyx")}) |
|
(0009710) Jacob Wieland - Spirent (reporter) 03-09-2010 12:18 |
Please review. |
|
(0009969) Ina Schieferdecker (reporter) 14-12-2010 15:00 |
Not yet finally agreed - shifted to 2011 for consideration |
|
(0010258) Gyorgy Rethy (reporter) 27-09-2011 17:59 |
Types are static in TTCN-3 to allow as deep compile time checking as possible. Also type constraints shall be resolvable compile time. Therefore any template used in a type constraint should have similar limitations as constants used in type constraints: should use only literals and constants obeying restriction b) of clause 10, predefined functions except of rnd , operators specified in clause 7.17.1, and other templates obeying the previous limitations. And, of course, it could only use the specific value, value list, complemented value list, AnyValue or AnyValueOrNone matchings. Seems to be much ado for almost nothing: for simple types range and list notations solve this task on a sufficient level today. For structured types, in addition, this - would make the semantics of templates different when used in type constraints or elsewhere in the code, implicitly supposing ? and * when used in type constraints and - force the user to declare named templates unnecesarily, causing extra work and decreising readibility (the user cannot really see what the type definition is). See proposed resolution in CR5262_resolution_v1.doc |
|
(0010260) Jacob Wieland - Spirent (reporter) 28-09-2011 11:18 |
I think you somehow misunderstood my proposal. To clarify: First, the restrictions implying compile-time resolvability are already in the proposal, I just did not want to re-iterate the same restrictions as for constants used in type definitions. Second, only literal compound expressions shall be interpreted as containing implicit ? or * fields (kind or as a shorthand notation for an inline-modifies construct). If actual named templates are used as a subtype constraint, they shall have the same semantics as everywhere else. Third, no one forces the user to define named templates. Everything can be done with inline constructs, if so desired. This allows exactly for the effects desired by the CR, but also much, much more. |
|
(0010288) Gyorgy Rethy (reporter) 29-09-2011 09:38 |
This CR is submitted two years ago. Basically my proposal is to handle it in two steps: cover the requested functionality (basically something similar but not fully equivalent to the ASN.1 table constraint) by this CR and open a new CR for the constraints by templates part that still needs some work to do. This would prevent further delay in resolving the originally requested feature. |
|
(0010291) Gyorgy Rethy (reporter) 29-09-2011 10:19 edited on: 29-09-2011 12:37 |
STF discussion 2011-09-29: de-couple the two features: type constraint by partially defined values and type constraints by template into separate CRs and try to resolve both for v4.4.1. |
|
(0010298) Gyorgy Rethy (reporter) 29-09-2011 12:39 |
Resolution draft for the partially defined value part is in CR5262_resolution_v1.doc. Pls. review. (the file CR5262.doc is moved to CR5938 under the name "CR5938_initial_draft.doc") |
|
(0010306) Jens Grabowski (manager) 30-09-2011 09:55 |
Resolution is fine with me. Assigned to Ina for integration into core language. |
|
(0010308) Gyorgy Rethy (reporter) 30-09-2011 11:10 |
Acc. to review the proposal is OK. |
|
(0010417) Ina Schieferdecker (reporter) 30-11-2011 09:33 |
as proposed. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 01-07-2009 14:51 | Gyorgy Rethy | New Issue | |
| 01-07-2009 14:51 | Gyorgy Rethy | Status | new => assigned |
| 01-07-2009 14:51 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker |
| 01-07-2009 14:51 | Gyorgy Rethy | Clause Reference(s) | => new 6.2.13 |
| 01-07-2009 14:51 | Gyorgy Rethy | Source (company - Author) | => L.M.Ericsson |
| 09-12-2009 15:42 | Ina Schieferdecker | Note Added: 0009125 | |
| 09-12-2009 15:42 | Ina Schieferdecker | Target Version | => Edition 5.1.1 (not yet published) |
| 22-03-2010 17:23 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => |
| 22-03-2010 17:23 | Gyorgy Rethy | Status | assigned => new |
| 23-03-2010 12:52 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent |
| 23-03-2010 12:52 | Gyorgy Rethy | Status | new => assigned |
| 23-03-2010 19:03 | Jacob Wieland - Spirent | Note Added: 0009270 | |
| 31-08-2010 11:45 | Jacob Wieland - Spirent | Note Added: 0009663 | |
| 01-09-2010 16:57 | Jacob Wieland - Spirent | File Added: CR5262.doc | |
| 01-09-2010 17:05 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy |
| 01-09-2010 17:05 | Jacob Wieland - Spirent | Note Added: 0009682 | |
| 03-09-2010 10:17 | Gyorgy Rethy | Note Added: 0009705 | |
| 03-09-2010 10:17 | Gyorgy Rethy | Note Edited: 0009705 | |
| 03-09-2010 12:18 | Jacob Wieland - Spirent | Assigned To | Gyorgy Rethy => Ina Schieferdecker |
| 03-09-2010 12:18 | Jacob Wieland - Spirent | Note Added: 0009710 | |
| 03-09-2010 13:17 | Jacob Wieland - Spirent | Status | assigned => resolved |
| 03-09-2010 13:17 | Jacob Wieland - Spirent | Fixed in Version | => Edition 4.3.1 (not yet published) |
| 03-09-2010 13:17 | Jacob Wieland - Spirent | Resolution | open => fixed |
| 14-12-2010 15:00 | Ina Schieferdecker | Note Added: 0009969 | |
| 14-12-2010 15:25 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Gyorgy Rethy |
| 14-12-2010 15:25 | Ina Schieferdecker | Status | resolved => assigned |
| 14-12-2010 15:25 | Ina Schieferdecker | Fixed in Version | Edition 4.3.1 (not yet published) => |
| 14-12-2010 15:25 | Ina Schieferdecker | Target Version | Edition 4.3.1 (not yet published) => Edition 4.3.2 (interim) |
| 27-09-2011 14:07 | Gyorgy Rethy | Target Version | Edition 4.3.2 (interim) => Edition 4.4.1 |
| 27-09-2011 17:59 | Gyorgy Rethy | Note Added: 0010258 | |
| 27-09-2011 18:08 | Gyorgy Rethy | File Added: CR5262_resolution_v1.doc | |
| 27-09-2011 18:10 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent |
| 28-09-2011 11:18 | Jacob Wieland - Spirent | Note Added: 0010260 | |
| 28-09-2011 13:16 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy |
| 29-09-2011 09:38 | Gyorgy Rethy | Note Added: 0010288 | |
| 29-09-2011 10:19 | Gyorgy Rethy | Note Added: 0010291 | |
| 29-09-2011 12:37 | Gyorgy Rethy | Note Edited: 0010291 | |
| 29-09-2011 12:39 | Gyorgy Rethy | Note Added: 0010298 | |
| 29-09-2011 12:39 | Gyorgy Rethy | File Deleted: CR5262.doc | |
| 29-09-2011 12:39 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski |
| 30-09-2011 09:55 | Jens Grabowski | Note Added: 0010306 | |
| 30-09-2011 09:56 | Jens Grabowski | Assigned To | Jens Grabowski => Ina Schieferdecker |
| 30-09-2011 11:10 | Gyorgy Rethy | Status | assigned => resolved |
| 30-09-2011 11:10 | Gyorgy Rethy | Note Added: 0010308 | |
| 30-11-2011 09:33 | Ina Schieferdecker | Note Added: 0010417 | |
| 30-11-2011 09:33 | Ina Schieferdecker | Status | resolved => closed |
| 30-11-2011 09:33 | Ina Schieferdecker | Fixed in Version | => Edition 4.4.1 |
| 10-07-2013 17:01 | Gyorgy Rethy | Relationship added | related to 0005938 |
|
Issue History |
| MantisBT 1.2.14 [^] Copyright © 2000 - 2024 MantisBT Team |
 |