ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005262Part 01: TTCN-3 Core LanguageNew Featurepublic01-07-2009 14:5130-11-2011 09:33
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.1.1 (published 2009-06) 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Clause Reference(s)new 6.2.13
Source (company - Author)L.M.Ericsson
Summary0005262: Partially constrained structured types
DescriptionToday 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.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0005938closed Gyorgy Rethy Type restriction by template list 
Attached Filesdoc CR5262_resolution_v1.doc (119,808) 27-09-2011 18:08
http://oldforge.etsi.org/mantis/file_download.php?file_id=2565&type=bug
Issue History
Date ModifiedUsernameFieldChange
01-07-2009 14:51Gyorgy RethyNew Issue
01-07-2009 14:51Gyorgy RethyStatusnew => assigned
01-07-2009 14:51Gyorgy RethyAssigned To => Ina Schieferdecker
01-07-2009 14:51Gyorgy RethyClause Reference(s) => new 6.2.13
01-07-2009 14:51Gyorgy RethySource (company - Author) => L.M.Ericsson
09-12-2009 15:42Ina SchieferdeckerNote Added: 0009125
09-12-2009 15:42Ina SchieferdeckerTarget Version => Edition 5.1.1 (not yet published)
22-03-2010 17:23Gyorgy RethyAssigned ToIna Schieferdecker =>
22-03-2010 17:23Gyorgy RethyStatusassigned => new
23-03-2010 12:52Gyorgy RethyAssigned To => Jacob Wieland - Spirent
23-03-2010 12:52Gyorgy RethyStatusnew => assigned
23-03-2010 19:03Jacob Wieland - SpirentNote Added: 0009270
31-08-2010 11:45Jacob Wieland - SpirentNote Added: 0009663
01-09-2010 16:57Jacob Wieland - SpirentFile Added: CR5262.doc
01-09-2010 17:05Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
01-09-2010 17:05Jacob Wieland - SpirentNote Added: 0009682
03-09-2010 10:17Gyorgy RethyNote Added: 0009705
03-09-2010 10:17Gyorgy RethyNote Edited: 0009705
03-09-2010 12:18Jacob Wieland - SpirentAssigned ToGyorgy Rethy => Ina Schieferdecker
03-09-2010 12:18Jacob Wieland - SpirentNote Added: 0009710
03-09-2010 13:17Jacob Wieland - SpirentStatusassigned => resolved
03-09-2010 13:17Jacob Wieland - SpirentFixed in Version => Edition 4.3.1 (not yet published)
03-09-2010 13:17Jacob Wieland - SpirentResolutionopen => fixed
14-12-2010 15:00Ina SchieferdeckerNote Added: 0009969
14-12-2010 15:25Ina SchieferdeckerAssigned ToIna Schieferdecker => Gyorgy Rethy
14-12-2010 15:25Ina SchieferdeckerStatusresolved => assigned
14-12-2010 15:25Ina SchieferdeckerFixed in VersionEdition 4.3.1 (not yet published) =>
14-12-2010 15:25Ina SchieferdeckerTarget VersionEdition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
27-09-2011 14:07Gyorgy RethyTarget VersionEdition 4.3.2 (interim) => Edition 4.4.1
27-09-2011 17:59Gyorgy RethyNote Added: 0010258
27-09-2011 18:08Gyorgy RethyFile Added: CR5262_resolution_v1.doc
27-09-2011 18:10Gyorgy RethyAssigned ToGyorgy Rethy => Jacob Wieland - Spirent
28-09-2011 11:18Jacob Wieland - SpirentNote Added: 0010260
28-09-2011 13:16Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Gyorgy Rethy
29-09-2011 09:38Gyorgy RethyNote Added: 0010288
29-09-2011 10:19Gyorgy RethyNote Added: 0010291
29-09-2011 12:37Gyorgy RethyNote Edited: 0010291
29-09-2011 12:39Gyorgy RethyNote Added: 0010298
29-09-2011 12:39Gyorgy RethyFile Deleted: CR5262.doc
29-09-2011 12:39Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
30-09-2011 09:55Jens GrabowskiNote Added: 0010306
30-09-2011 09:56Jens GrabowskiAssigned ToJens Grabowski => Ina Schieferdecker
30-09-2011 11:10Gyorgy RethyStatusassigned => resolved
30-09-2011 11:10Gyorgy RethyNote Added: 0010308
30-11-2011 09:33Ina SchieferdeckerNote Added: 0010417
30-11-2011 09:33Ina SchieferdeckerStatusresolved => closed
30-11-2011 09:33Ina SchieferdeckerFixed in Version => Edition 4.4.1
10-07-2013 17:01Gyorgy RethyRelationship addedrelated to 0005938

Notes
(0009125)
Ina Schieferdecker   
09-12-2009 15:42   
A proposal has to be developed first - hence postponed to 2010.
(0009270)
Jacob Wieland - Spirent   
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   
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   
01-09-2010 17:05   
please review
(0009705)
Gyorgy Rethy   
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   
03-09-2010 12:18   
Please review.
(0009969)
Ina Schieferdecker   
14-12-2010 15:00   
Not yet finally agreed - shifted to 2011 for consideration
(0010258)
Gyorgy Rethy   
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   
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   
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   
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   
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   
30-09-2011 09:55   
Resolution is fine with me. Assigned to Ina for integration into core language.
(0010308)
Gyorgy Rethy   
30-09-2011 11:10   
Acc. to review the proposal is OK.
(0010417)
Ina Schieferdecker   
30-11-2011 09:33   
as proposed.