TOPIC:

Hmmm, I get the feeling certain people are not trying to understand very
hard!

One more time.

Current syntax subtype on a field:

type record MyType
{
charstring field1 length (10) --******NOTE: TYPE IDENTIFIER
LENGTH CONSTRAINT*****
}

subtype definition:

type charstring MySubType length (10) --******NOTE: TYPE IDENTIFIER
LENGTH CONSTRAINT*****

Now lets have a little look at your proposal:

Type [SubTypeSpec] (StructTypeIdentifier | AddressKeyword) [SubTypeSpec]
/* Static semantics:
The first optional SubTypeSpec restricts the values of the
content elements of the struct-of type to be declared.
The second optional SubTypeSpec restricts the length or values
of the struct-of type to be declared. */

So for a length constraint of the type

set of charstring length 10 My type --******NOTE: TYPE LENGTH
CONSTRAINT IDENTIFIER*****

Now let look at the STF187 proposed solution:

set of charstring My type length 10 --******NOTE: TYPE IDENTIFIER
LENGTH CONSTRAINT *****

Now please which solution is consistent with the existing syntax and which
not? (hint look at the
comments!)

Note: The STF187 proposed solution comes directly from ASN.1 (please see
clause 42.4 in X.680).
This has at least 10 years on development behind it, it works, it is the
standard way to do this,
please we have more important things to do than reinvent the wheel.

BR Colin.

---

Original Message

---

From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 18 October 2001 13:29
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Draft texts for TTCN-3 edition 2


On Tue, 16 Oct 2001, Colin Willcock wrote:

> Regarding the following point made by Jacob 'Ugh' Wieland
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]:
>
> > In the BNF:
>
> > I would strongly suggest that the length restriction for
> >'record of' and 'set of' types should have the same syntax
> >as that for string subtypes (where the length restriction
> >is placed BEHIND the defined type identifier instead of BEFORE
> >it).
>
> >All these types are some sort of 'list' type (which is why they
> >share the length restriction) and thus should be used similarly
> >so as not to confuse the user of the language.
>
> Please note the proposed solution is not possible for exactly the
> reason that a 'record of' can be a 'record of' string type and would
> therefore be a list of lists and require two possible length constraints.

Now, you're confusing me totally.

As I had only read the proposed sections of the review (and the
proposals on this list) and not every single rule in the updated BNF,
I was not aware of the change that a SubTypeSpec could be at the
end of a StructOfDefBody.

But, if that is the case, then knowing the rest of TTCN-3
(especially the SubtypeDef), I would assume that the restriction
is to the type to be declared and not the element-type it is
derived of.

Some examples what the restrictions can be used to do
(in my up-till-now understanding):

type charstring Type_1 length(10)
type charstring Type_2 ("abc", "def")
type record of integer Type_3 length(10)
type record of integer Type_4 ({1,2,3},{4,5,6})
type record of charstring Type_5 length(10)
type record of charstring Type_6 ({"abc","def"}, {"ghi", "jkl"})

If you wanted to restrict the _element_ type additionally,
I would assume it far more logical to append that restriction
to that type in the declaration:

type record of charstring length(10) Type_7 lenght(10)

which would mean the same as:

type record of Type_1 Type_7 length(10),

i.e. a type of records of length 10 of charstrings of the length 10.

If what you are saying shall be the case, then this makes the
language design for record of types and string types very
unorthogonal and thus probably not very understandable,
especially if you have not sufficient examples to explain
the different statements.

Up till now, I thought the general approach to type definition
was:

type <type> <identifier> [<parameters>] [<body>|<restriction>]

where <type> could be
union, record, set, record of <type>, set of <type>, <stringtype>,
component, port, enumerated, <type_identifier> or <type_instance>.

In the case of record of and set of types, this could be
modified to 'record of <type> [<restriction>]' and
'set of <type> [<restriction>]', but this is not necessary
as a type with that restriction could have been declared
by itself and used in the record of declaration.

To summarize my proposal:


Either:
leave out the (in my view unnecessary) possible element-type
restrictions in record of and set of type declarations
Or:
append the element-type restrictios in record and set of type
declarations to the element type and not to the type declaration
(i.e. the declared record of or set of type)
In any case:
let the subtype-restriction appended to record of and
set of type declarations mean the same as for string-type
declarations: restriction on the declared type, not the contents!

In terms of the BNF:

RecordOfDef ::= RecordKeyword OfKeyword StructOfDefBody
SetOfDef ::= SetKeyword OfKeyword StructOfDefBody
StructOfDefBody ::=
Type [SubTypeSpec] (StructTypeIdentifier | AddressKeyword) [SubTypeSpec]
/* Static semantics:
The first optional SubTypeSpec restricts the values of the
content elements of the struct-of type to be declared.
The second optional SubTypeSpec restricts the length or values
of the struct-of type to be declared. */

Greetings, Jacob Wieland, TU-Berlin

PS:

> e.g. In the following type there are two lengths I need to constrain. The
> length (no of elements) of the 'record of' and the length of the octet
> strings
>
> type record of octetstring MyExampleType
>
> If I wish to constrain the octet string then I write:
>
> type record of octetstring MyExampleType length(7)
>
> Which is exactly the same as the subtype syntax.

It may be the same syntax, but it is used with a different semantics
which makes it so confusing to me.

On Thu, 18 Oct 2001, Colin Willcock wrote:

> Hmmm, I get the feeling certain people are not trying to understand very
> hard!
>
> One more time.
>
> Current syntax subtype on a field:
>
> type record MyType
> {
> charstring field1 length (10) --******NOTE: TYPE IDENTIFIER
> LENGTH CONSTRAINT*****
> }

type record MyType
{
// Note: typekind type constraint identifier constraint
record of integer length(10) field1 length(10)
>
> subtype definition:
>
> type charstring MySubType length (10) --******NOTE: TYPE IDENTIFIER
> LENGTH CONSTRAINT*****

// Note: typekind type constraint identifier constraint
type record of integer length(10) MySubType length(10)
>
> Now lets have a little look at your proposal:
>
> Type [SubTypeSpec] (StructTypeIdentifier | AddressKeyword) [SubTypeSpec]
> /* Static semantics:
> The first optional SubTypeSpec restricts the values of the
> content elements of the struct-of type to be declared.
> The second optional SubTypeSpec restricts the length or values
> of the struct-of type to be declared. */
>
> So for a length constraint of the type
>
> set of charstring length 10 My type --******NOTE: TYPE LENGTH
> CONSTRAINT IDENTIFIER*****

No! It is: TYPE IDENTIFIER (without LENGTH CONSTRAINT) - as you like it
(with the additional feature that TYPE also can carry a length constraint)

> Now let look at the STF187 proposed solution:
>
> set of charstring My type length 10 --******NOTE: TYPE IDENTIFIER
> LENGTH CONSTRAINT *****
>
> Now please which solution is consistent with the existing syntax and which
> not? (hint look at the
> comments!)

Mine also. As shown above.

> Note: The STF187 proposed solution comes directly from ASN.1 (please see
> clause 42.4 in X.680).
> This has at least 10 years on development behind it, it works, it is the
> standard way to do this,
> please we have more important things to do than reinvent the wheel.

I don't try to reinvent the wheel, but to give a consistent semantics
to the syntax of the subtype declaration and the record/set of
declaration. If in one type, the length constraint after the declaration
constrains the new type and in one case it constrains the CONTENT-elements
of the type, this is inconsistent, no matter how many experience there is
with that syntax.

Just to show you, how inconsistent:

type charstring C;
type C C2 length(10);
// should mean the same as:
type charstring C2 length(10)
// i.e. C2 is the type of charstrings of length 10

type record of charstring R;
type R R2 length(10);
// should mean the same as:
type record of charstring R2 length(10)
// i.e. R2 is the type of (records of charstring) of length 10

But, as I understand you, the first would mean:
R2 is the type of (records of charstring) of length 10
and the second (as I understand the revisions proposal):
R2 is the type of (records of (charstring of length 10))

The second is radically different than for the
subtype scenario, although it looks exactly the same.

This cannot be good!

Greetings, Jacob