Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: referencing record of elements

referencing record of elements 03 Jul 2012 13:03 #6173

Hello all,
I have some questions regarding access of record of template elements
(ES 201873-1 - v 4.4.1, section 15.6.3).
//given following situation:
type record of integer RoI;
 
var RoI vroi := {1,*,5}
vroi[2] := 2; // is this allowed or does the same rule apply like in case of vroi := *
 
vroi := {?,2,*}
vroi[3] := 4; // is this allowed, and if yes, would the outcome be something like {?, 2, <uninitialized>, 4, *}
 
vroi := ?;
vroi[1] := 2;// this for instance is allowed and would produce the same template as in the previous initialisation of vroi: {?, 2, *}
vroi[3] := 4; // this case seems to be allowed too and it would produce a vroi: {?, 2, ?, 4, *}
Any suggestions are welcome as I was not able to determine this from the
core language specification

Best Regards,
Uwe
Last Edit: 04 Jul 2013 08:34 by Denis Filatov. Reason: ttcn-3 code
The administrator has disabled public write access.

referencing record of elements 04 Jul 2012 07:48 #6174

Hi all,

Please find Elvior’s answer below.

We will also rise CR on this matter.

BR,
Andrus Lehtmets
Elvior

From: Tomas Urban
Sent: Wednesday, July 04, 2012 10:34 AM
To: Andrus Lehtmets (Elvior)
Subject: Re: Fw: referencing record of elements


First of all, all those assignments are invalid for a simple reason. The "vroi" variable is not a template variable, so it is not allowed to assign matching symbols to it.

If that the variable "vroi" were declared correctly as a template variable:

1. The first example would be correct. There's no rule forbidding overwriting of individual record of elements with a new value.
2. The 2nd and 3rd example should produce the same result. However, I am afraid that ES 201873-1 4.4.1 doesn't give a good guidelines for this situation. There is no rule in 15.6.3 (or anywhere else) saying that a mechanism similar to the one described in the paragraph 15.6.3.b shall be applied to record of values containing AnyElementsOrNone as the last element. However, you can find application of this non-existent rule in the example section. So there's definitely a problem with the specification. I will submit a CR regarding this issue.
Anyway, the result would be either:
Assuming that there's no rule regarding terminating AnyElementsOrNone, the element should be simply appended to the original template (using rules from the chapter 6.2.3): { ?, 2, *, 4 }
Using the same mechanisms as in the examples from the chapter 15.6.3.b: { ?, 2, ?, 4, *}

Our tool uses the latter approach.

--Tom
Last Edit: 04 Jul 2013 08:35 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 04 Jul 2012 07:48 #6175

thank you Tom, for your reply.
Of course you where right with the variable declaration. It was intended
to be a var template.
Nevertheless I still have some questions regarding the first example:
var template RoI vroi := {1,*,5}
vroi[2] := 2;

If used in a match operation vroi would treat the '*' as a real
AnyElementOrNone, i.e. it would match zero or more elements from the
provided value.
So from your point of view accessing an element of vroi would treat the
'*' as a single element. Is this somewhere specified in the standard?
In this case the above example would provide us with following content
of vroi: {1,*,2}
vroi[1] := 0; // vroi -> {1, 0, 2}    is this correct?
What if we'd have the element access on the right hand side of an
assignment:
var template RoI vroi := {1,*,5}
log(vroi[1], vroi[2]); // -> "*5"

BR.,
Uwe
Last Edit: 04 Jul 2013 08:37 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 04 Jul 2012 11:20 #6176

Hello,

we agree in general with the assessment of Elvior.
The standard maybe is not explicit enough, although implicitly, the rule
15.6.3. b) is clear as always the relation

? =^= {*} for record of/set of templates is true.

The example which assigns a matching mechanism to an element which is
covered by an * (AnyElementsOrNone) confirms this interpretation.

Therefore, we at Testing Tech do not think it really necessary to change
the standard, but as long as the interpretation given also by Elvior is
maintained, we will support a CR in that regard.

BR, Jacob Wieland
Last Edit: 04 Jul 2013 08:38 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 04 Jul 2012 11:20 #6177

I totally agree on the case that no element from inside permutation
should be accessible but I'm questioning the wording of 15.6.3.c as I do
not understand the difference between the case with and the one without
'permutation'.

this is getting very speculative if one would write something like this:
t_RoI := {permutation(0,1,3,* length(2)),2,?}
t_Int := t_RoI[5];
In this case none can say that all elements of the record of are
sheltered. Arguing with the fixed length applied to '*' t_RoI[5] == 2,
which of course is not what we would expect in case we have something like
t_RoI := {0,1,3,* length(2),2,?}
t_Int := t_RoI[5];  // t_RoI[5] == ?

BR.,
Uwe
Last Edit: 04 Jul 2013 08:39 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 05 Jul 2012 08:41 #6178

Sorry for the inconvenience, but I had problems with the time keeping
of my machine. According to this I sent the message back in July 2004.
Now I re-send it with the proper timestamp.

BR.,
Uwe
Last Edit: 04 Jul 2013 08:40 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 06 Jul 2012 09:05 #6179

Hello Uwe,

I would expect t_RoI[5] to be 2 in both cases.

BR, Jacob Wieland
Last Edit: 04 Jul 2013 08:40 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 06 Jul 2012 09:28 #6180

Hello Jacob,
further down this email thread we already discussed access of record of
template elements via index.
Tomas Urban's opinion about accessing such templates was that '*' counts
as one single element of the record of:
var template RoI vroi := {1,*,5}
vroi[2] := 2; // ->{1,*,2}
vroi[1] := 3; // -> {1,3,5}

If the above behaviour is correct then I would expect
var template RoI vroi := {0,1,3,* length(2),2,?}
vroi[4] := 5; // ->{0,1,3,* length(2),5,?}
vroi[3] := 4; // ->{0,1,3,4,5,?}

Following your opinion
var template RoI vroi := {1,*,5}
vroi[2] := 2; // this will produce an error as it tries to index  something which is covered by the '*'

So which behaviour should be the correct one:
does one ignore the matching capabilities of '*'/'*' length(...) while
trying to access elements of a record of template
or not?

BR.,

Uwe
Last Edit: 04 Jul 2013 08:41 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 06 Jul 2012 10:35 #6181

Hello Uwe,

No, * in a record of is not a single element but represents an arbitrary number (from zero to infinity) of elements.

{*} is semantically equivalent to ({}, {?}, {?,?}, ...) (and {x, y, z, *, a, b, c} is equivalent to { x, y, z } & {*} & { a, b, c})

Thefore, the indices of elements following a * are undetermined (which is why they can never be accessed). If the star is length-restricted with a fixed length however, this changes.Then it is equivalent with the same number of ? as in the length restriction and the following elements again have fixed indices.

A permutation construction is pretty much the same as a special *, so the same rules apply to elements after it.

So, no, I would not say that the matching capabilities of * should be ignored when accessing the element-templates.

BR, Jacob Wieland
Last Edit: 04 Jul 2013 08:42 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 09 Jul 2012 13:23 #6182

Hello Jacob,
thanks for your explanation.
Thus my conclusion is that
RoI var template vroi := {1, *, 2};
vroi[1] := 1; // ok -> {1, 1, 2}

further on
RoI var template vroi := {1, *, 2};
vroi := {10, -, 20 } // -> error, as index 2 crosses the index of '*' of  the original value
vroi := {-, 20} // ok -> {1, 20}
 
vroi := {1, permutation(10, 20), 2}
vroi := {11, -, -, 12} // -> ok as permutation elements remain untouched
vroi := {11, 12, - 12} // -> error: as not the whole permutation gets  overwritten
 
vroi := {11, 12}; // -> from 6.2.3 example 2 I would say it is allowed  and the result is {11, 12}, nevertheless index 1 is originally part of a  permutation and thus this should be an error.
What is your opinion about this?

BR.,
Uwe
Last Edit: 04 Jul 2013 08:44 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 09 Jul 2012 14:04 #6183

Hi,

We also agree. In case of example 1, Currently there is no rule how to calculate the position of elements following AnyElementOrNone at assignments. So, the task here is to define this rule.
The rules used for examples 2 and 3 should explicitly be defined as mandatory rules in the text.

BR, Gyorgy
Last Edit: 04 Jul 2013 08:45 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 10 Jul 2012 07:09 #6184

A different scenario with '*' and '-' on the right hand side of an
assignment:
RoI var template vroi := {1, 2, 3}
vroi := {*, -, 4};

what should be the result of this assignment? I'm not even sure if
this is legal ttcn-3 code. In the spec I just found the value list
assignment containing '-' on the right hand side having non-template
values involved in the operation.
What is your opinion about this?

BR.,
Uwe
Last Edit: 04 Jul 2013 08:45 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 10 Jul 2012 11:14 #6185

I would think that the template then would evaluate to {*,-,4}. To
MODIFY the value of { 1, 2, 3 }, only the index-assignment notation can
be used (and here, the - would still have the meaning of undefined, and
not unchanged. The dash has the meaning unchanged only in the modified
templates construction, i.e.
the question would be, what is the meaning of vroi in the following
construction.
var template RoI vroi1 := {1,2,3}
var template RoI vroi := {*,-,4} modifies vroi1;

In my opinion, it would still be {*,-,4} as it is unclear, how many
elements the * replaces (and thus, which element the unchanged would
leave unchanged).
To avoid confusion between undefined and unchanged, maybe this situation
should be forbidden.

BR, Jacob Wieland
Last Edit: 04 Jul 2013 08:46 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 10 Jul 2012 12:44 #6186

Not allowing this situation might be a good idea.
Nevertheless, I suppose you agree with me, that the following code
var template RoI vroi := {1,2,3}
vroi := {-, 20}; // leads to this outcome: vroi == {1, 20}
unfortunately it is not specified inside the standard how '-' is handled together with matching symbols inside a value list notation on the right hand side of an assignment.

If this is intended it should be written down in the standard that using '-' on the right hand side of an assignment to a var template is not allowed.
Maybe we should issue a CR regarding this behaviour.

Still I think having a '-' before a '*' could still be possible
var template RoI vroi := {1,2,3}
vroi := {-, *}; // would then lead to vroi == {1,*}

Sorry if I'm asking it again, but there are still some unclear things I mentioned further down in this email thread which have not been answered yet.
Namely:

RoI var template vroi := {1, *, 2};
vroi[1] := 1; // ok -> {1, 1, 2}

further on
RoI var template vroi := {1, *, 2};
vroi := {10, -, 20 } // -> error, as index 2 crosses the index of '*' of the original value
vroi := {-, 20} // ok -> {1, 20}
 
vroi := {1, permutation(10, 20), 2}
vroi := {11, -, -, 12} // -> ok as permutation elements remain untouched
vroi := {11, 12, - 12} // -> error: as not the whole permutation gets overwritten
 
vroi := {11, 12}; // -> from 6.2.3 example 2 I would say it is allowed 
                //and the result is {11, 12}, nevertheless index 1 is originally part 
                //of a permutation and thus this should be an error.
What is your opinion about this?

BR.,
Uwe
Last Edit: 04 Jul 2013 08:49 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 13 Jul 2012 06:49 #6187

I have to apologise that the discussion disappeared from the mailing
list. It was my fault as I replied only to Jacob Wieland.
Here it comes again.

BR.,
Uwe
Last Edit: 04 Jul 2013 08:50 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 16 Jul 2012 07:02 #6188

Hello all,
during my examination of recordof I stumbled over a case where I need some clarification:
What happens when a AnyValueOrNone is assigned to a recordof element:
var template RoI vroi := {1, 2, 3};
vroi[1] := *;

is this allowed and if yes, is the meaning of '*' transformed to AnyElementOrNone.

Further on I'd like to know whether the following case is equivalent to the original example:

var template RoI vroi := {1, 2, 3};
var template integer v_i := *;
vroi[1] := v_i;


BR.,
Uwe
Last Edit: 04 Jul 2013 08:51 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 16 Jul 2012 08:48 #6189

Hello,

I don't think it should be allowed, or, if it is allowed, it should yield the semantic equivalent of { ?, 2, 3 }.

It should definitely not yield the semantics of { *, 2, 3 } as that would totally change the semantics of the from AnyElementOrNone to AnyElementsOrNone.

The ? has the same semantics as integer:* in a context where no omit can occur (as is the case in a record of).

BR, Jacob Wieland
Last Edit: 04 Jul 2013 08:52 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 16 Jul 2012 09:38 #6194

Do you think I should raise a CR for this?
Though the semantic equivalent should be rather {? ifpresent, 2, 3} as
each element of a recordof can be regarded as being optional

BR.,
Uwe
Last Edit: 04 Jul 2013 08:53 by Denis Filatov. Reason: Remove original message
The administrator has disabled public write access.

referencing record of elements 16 Jul 2012 09:43 #7798

Once, I thought so, too. But this view is not standard conform. An element of a record of value is either undefined or defined, never omit (though the distinction between omit and undefined is largely academic ;-))

So, yes, implicitly, it would be '? ifpresent', but since the ifpresent part has no effect inside a recordof as no field can be omit, this is equivalent to simply '?'.

If that is not clear from the standard, then a CR for clarification is warranted.

BR, Jacob Wieland
Last Edit: 30 Jul 2013 09:32 by Denis Filatov.
The administrator has disabled public write access.

referencing record of elements 16 Jul 2012 10:32 #7799

Hi,


I think this shall be clear from table 11 in clause 15.7.1, where NOTE 1 , attached to each Yes for IfPresent says: " NOTE 1: Can be assigned to templates, however when used shall be applied to optional fields of record and set types only (without restriction on the type of that field)."
(the note also applies to omit and *).

But what "when used" does mean is being clarified in CR 6016: t-ort.etsi.org/view.php?id=6016.

To it sum up shortly:
template integer t_int := 1 ifpresent // is allowed
template MyRecord t_rec := { mandatoryField := 1, optionalField := t_int } // is allowed; actually, this is the purpose of allowing ifpresent for all types
match (t_int,1) // shall cause an error , t_int shall not contain *, omit or ifpresent, when used for matching (defined today).
 
template RecordOf t_recof := { ? ifpresent, 2, 3 } // is not forbidden today, but useless, as t_recof[0] on the right hand side of an assignment, if it references something that is omit, * or ifpresent, causes an error; so, CR 6016 should also forbid assigning it to a t_recof element, thus at least in some cases this problem would cause a compile time error instead of a runtime error.
match (t_recof, { ?, 2, 3 }) // causes an error, because a record of element shall not contain omit, * or ifpresent when used for matching (defined today).
As Jacob explained, omit, * and ifpresent make sense only for optional fields, which have 3 states: unbound, something is assigned or missing (identified by omit). Missing and unbound is not the same. Missing is also an information, it means that the information is not included into the message intentionally; in many cases it carries a semantic meaning in the protocol, i.e. the state machine may change its state differently, depending if some information is present or not. In some cases (e.g. in ASN.1 PER) omitted elements are explicitly encoded. While unbound is simply "unknown", it is not defined.


BR, Gyorgy
Last Edit: 30 Jul 2013 09:34 by Denis Filatov.
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin