SDL-News: SDL Task Force to Jens: Example of why save is needed please...

Subject: SDL-News: SDL Task Force to Jens: Example of why save is needed please...
From: William H. Skelton (
Date: Sat Dec 06 2003 - 02:00:03 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From "William H. Skelton" <> to sdlnews -----

Dear Jens (& others not on the task force mailing list),

The save discussion is still ongoing at the task force (with a surprising
amount of activity actually); if you didn't register you may not be on the
distribution list. Rick and I can forward your request, but we are not the
contact persons, there is a web-site at

I expect one of our task force administration colleagues will add your name
now anyway, but if you don't see anything from us please register!

The answer to your email (and others) was in effect please take one example
from your 53 cases, if you have a moment, and let us know why it couldn't
be better handled with a queue based on 'sequence of' plus relevant operators.

If you didn't see previous comments on the task force, a limitation with
save has been identified that you can't flush saved signals without losing
new arrivals of the same signal. Your comments about how your application
avoided this problem would be appreciated.

Looking forward to your comments to the task force... :-)


>Date: Fri, 05 Dec 2003 11:35:49 +0100
>From: Jens Grabowski <>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
>X-Accept-Language: en-us, en
>To: "William H. Skelton" <>
>Subject: Re: SDL-news: Fwd: Re: [SDLTF-Members] Summary of SAVE Issues
>X-RCPT-TO: <>
>... I am really suprised about this discussion ...
>The last bigger SDL-based project I was involved in was test generation
>for Core INAP CS 3. This was two years ago. I just counted the used SAVE
>constructs used in the SDL/PR file of this specification and the number is 53.
>I think I also remember that I have seen some 'informal' SAVE constructs
>in some older ITU-T standards.
>However, if you delete the SAVE construct, you need some other mechanism
>which allows you to re-order the input queue of a process. Forcing the
>user to implement his own mechanism each time he needs a special
>evaluation order of signals would not be a good idea.
>Just a small comparison to TTCN: In TTCN you don't need a SAVE construct,
>because each test component manages several input queues and the
>programmer can decide in which order a test component shall remove signals
>from these queues (and thus, decide which signals shall remain in the
>queues for later computation). In order to make this selection
>deterministic, the order of writing determines in TTCN the order in which
>the queues and signals are examined. The snapshot-semantics defines the
>relevant queue-state, i.e., the signals in the queues which are considered
>in the evaluation process. This snapshot-semantics avoids non-determinism
>due to signals arriving during the evaluation process, i.e., such signals
>are not considered in the evaluation process.
>In SDL, the latter two kinds of non-determinism (i.e., evaluation order
>and arrival of signals during the evaluation process) are avoided by
>having only one input queue and by having only access to the first element
>in the input queue. Therefore, SDL needs no snapshot, but in my opinion it
>needs a standardized way to select/consume/identify signals in the queue.
>The SAVE construct is a minimalistic way, which allows to reorder the
>queue according to a required evalutation order. You can also think of
>more sophisticated queue re-order operations, the introduction of several
>queues (+ change of operational semantics) or as described by William to
>force the specifier to implement his own proprietory
>queue-handling-mechanism by using SEQUENCE-OF data structures. Again in my
>personal opinion, the latter would be the worst-case scenario for the
>usability of SDL.
>Hope I didn't bore you too much with already known issues.
>Have a nice weekend.
>Jens Grabowski
>P.S. Rick, I don't know if my new Email address
> allowes me to send to
> and If not please forward it.
>William H. Skelton wrote:
>>Become an SDL Forum Society member
>>The originator of this message is responsible for its content.
>>-----From "William H. Skelton" <> to sdlnews -----
>>Dear Rick,
>>Thank you for your comments, which correct my hurried inaccuracies in detail.
>>The big picture still remains valid in my opinion and the length of
>>explanation needed to counter what I have expressed in a couple of
>>sentences surely indicates the complexity of what apparently is being
>>defended as simple.
>>I repeat, save is not in the subset for the reason that is not essential!
>>It is not a question of how nice the feature is or how useful it is or
>>how it works even; only if there is a 'need' for it that cannot be
>>fulfilled by a simple mechanism already in the subset, such as SEQUENCE OF.
>>It would be nice if we could keep these issues separate. :-)
>>More comments below...
>>>Date: Thu, 04 Dec 2003 21:45:27 +0000
>>>Subject: Re: [SDLTF-Members] Summary of SAVE Issues Discussed
>>>From: Rick Reed TSE <>
>>>To: <>
>>>CC: SDLnews <>
>>>William H. Skelton at wrote on 04/12/2003 18:31:
>>> > 1.2) There has been confusion about how the save construct works and
>>> why it
>>> > is useful (execution model is not transparent, inter-state
>>> dependencies are
>>> > created). Apart from state reduction, there have been no applications
>>> > presented where it is needed (William).
>>>I would be surprised if anyone that has used SDL tools such as Cinderella,
>>>GEODE or SDT to any extent is confused about the way that SAVE works.
>>But there has been confusion and also a large number of emails and
>>paragraphs of detail explaining it. Furthermore part of the problem lies
>>in looking at the effect on other features.
>>>I do not agree with the analysis that "Apart from state reduction, there
>>>have been no applications presented where it is needed". It seems to me that
>>>several examples were given, and Philipp gave an example that is difficult
>>>to put into SDL without SAVE, because there is a state explosion otherwise.
>>State explosion is what state reduction is trying to avoid, right? :-)
>>No examples were given where it is needed; all examples for buffering
>>data could be handled with SEQUENCE OF and you showed that Philipp's
>>example could be done a different way yourself!
>>> > 1.4) Spontaneous transitions are not in the subset; are they needed
>>> (Philipp)?
>>>If the subset is to enable test stubs to be written, then I would think they
>>>would be needed.
>>As someone not familiar with this subject it would useful to understand
>>what test stubs are and why spontaneous transitions help. It may have a
>>bearing on the issues related to test requirements.
>>> > 2.1) There are no operators in pre SDL-2000 that allow SEQUENCE OF to be
>>> > manipulated(!!!)
>>>This is an incorrect statement.
>>>The operators were defined when it was allowed to use ASN.1 data with SDL -
>>>standardised by Z.105 March 1995.
>>>These operators are supported by SDL tools.
>>To save time, it would help if you could list these for us, as previous
>>emails had lead to this conclusion. From Alki's comments we need add to
>>back, remove from front, clear, possibly more, but I have not seen an
>>answer how this is supported already.
>>> > and SDL-2000 strings and operators are not in the SDL
>>> > subset.
>>>Strings are not an SDL-2000 feature. They existed in SDL-92, SDL-88 and
>>Your example to the task force was a more complex use of strings, that
>>looked to me like strings of data-types with generic operators for
>>working on them. But I have to admit I only scanned those comments
>>quickly; have I missed the point?
>>>I was under the impression that the supported data types and operations were
>>>under discussion.
>>We have identified in the first task force discussions that the ASN.1
>>data types, in principle according to X.680, are the minimum
>>requirement. The mechanisms you presented for implementing queues seemed
>>to use much more advanced features, which lead others to comment on their
>>complexity compared to what was under discussion.
>>The main point here is the use of literals, operators(!) and a
>>double-check if anything is missing.
>>> > An analysis of how to use SDL-2000 operators on SEQUENCE OF, which
>>> > is a valid SDL/ASN.1 type in the subset, is pending (Alkis).
>>>Is there a good reason to deviate from ITU-T SDL?
>>That is what we are trying to find out! :-)
>>And so far I think the progress is surprisingly good, not least due to
>>your help in clarifying some of the opaque issues!
>>>Rick Reed -
>>>Tel:+44 15394 88462 Mob.:+44 7970 50 96 50
>>William H. Skelton, Engineering Dept.
>>SOLINET GmbH Solutions for Innovative Networks
>>Mittlerer Pfad 26, 70499 Stuttgart, Germany
>>Tel +49 711 1398 1377, Fax +49 711 866 1240
>>Mobile +49 171 247 6688
>>--End text from "William H. Skelton" <> to sdlnews ---
>>For extra SDL Forum Society benefits join at
>>For help, email "" with the body of your email as:
>> help
>>or (iff this does not answer your question) email:
>Prof. Dr. Jens Grabowski
>Institute for Informatics phone: +49 551 39 14690
>University of Goettingen fax: +49 551 39 14415
>Lotzestrasse 16-18
>DE-37083 Göttingen

William H. Skelton, Engineering Dept.
SOLINET GmbH Solutions for Innovative Networks
Mittlerer Pfad 26, 70499 Stuttgart, Germany
Tel +49 711 1398 1377, Fax +49 711 866 1240
Mobile +49 171 247 6688,

--End text from "William H. Skelton" <> to sdlnews ---
For extra SDL Forum Society benefits join at <>

This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT