Subject: Re: SDL-News: SDL Task Force to Jens: Example of why save is needed please...
From: Jens Grabowski (grabowski#informatik.uni-goettingen.de)
Date: Mon Dec 08 2003 - 18:10:56 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Jens Grabowski <grabowski#informatik.uni-goettingen.de> to sdlnews -----
Dear William,
the Core INAP CS-2 and C-3 SDL specifications were developed at ETSI as
part of the IN standardization. I was mainly involved in the validation
of and test case generation from these Specs.
However, there is no doubt that it is possible to re-implement signal
queues by using SEQUENCE OF or other Data structures. And thus, it is
always possible to replace the SAVE construct by a proprietory
mechanism. But this statement doesn't mean that the SAVE construct is
not needed, because you can always replace it. Or do we need no
high-level programming language at all, because we can program
everything directly in Assembler?
The SAVE construct provides a certain level of abstraction. The usage of
a SAVE expresses that the specified signals are not handled here (i.e.,
consumed or implicitly discarded), but somewhere else. If the SAVE
construct is deleted from the language, this level of abstraction is
lost, i.e., all signals have to be consumed explicitly and pushed onto a
proprietory queue. A structuring of a process in e.g. procedures would
be very difficult, because the different procedures have to know the
SEQUENCE OF-structure and possibly all signals relevant for the other
procedures (otherwise it cannot consume and save these signals).
The argument with the flushing I don't understand. The SAVE construct is
simply not designed for this functionality. In the Core INAP case all
signals are handled and flushing is not required. If this
flushing-functionality is needed, you have to add this functionality to
the language (but I doubt that flushing only is related to SAVE).
Best regards
Jens Grabowski
William H. Skelton wrote:
> Become an SDL Forum Society member
> <http://www.sdl-forum.org/Society/members.htm>
> The originator of this message is responsible for its content.
> -----From "William H. Skelton" <W.Skelton#SOLINET.com> 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
> www.SDL-Task-Force.org.
>
> 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... :-)
>
> William
>
>> Date: Fri, 05 Dec 2003 11:35:49 +0100
>> From: Jens Grabowski <grabowski#informatik.uni-goettingen.de>
>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
>> Gecko/20030624
>> X-Accept-Language: en-us, en
>> To: "William H. Skelton" <W.Skelton#SOLINET.com>
>> CC: members#sdl-task-force.org, sdlnews#sdl-forum.org,
>> rickreed#tseng.co.uk
>> Subject: Re: SDL-news: Fwd: Re: [SDLTF-Members] Summary of SAVE Issues
>> Discussed
>> X-RCPT-TO: <W.Skelton#solinet.com>
>>
>> ... 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
>> grabowski#informatik.uni-goettingen.de allowes me to send to
>> members#sdl-task-force.org and sdlnews#sdl-forum.org. If not please
>> forward it.
>>
>> William H. Skelton wrote:
>>
>>> Become an SDL Forum Society member
>>> <http://www.sdl-forum.org/Society/members.htm>
>>> The originator of this message is responsible for its content.
>>> -----From "William H. Skelton" <W.Skelton#SOLINET.com> 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...
>>> William
>>>
>>>> Date: Thu, 04 Dec 2003 21:45:27 +0000
>>>> Subject: Re: [SDLTF-Members] Summary of SAVE Issues Discussed
>>>> From: Rick Reed TSE <rickreed#tseng.co.uk>
>>>> To: <members#sdl-task-force.org>
>>>> CC: SDLnews <sdlnews#sdl-forum.org>
>>>>
>>>> William H. Skelton at W.Skelton#SOLINET.com 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
>>>> SDL-84.
>>>
>>>
>>> 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 - rickreed#tseng.co.uk
>>>> 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
>>> W.Skelton#SOLINET.com, www.SOLINET.com
>>>
>>> --End text from "William H. Skelton" <W.Skelton#SOLINET.com> to
>>> sdlnews ---
>>> For extra SDL Forum Society benefits join at
>>> <http://www.sdl-forum.org/Society/members.htm>
>>> For help, email "majordomo#sdl-forum.org" with the body of your email
>>> as:
>>> help
>>> or (iff this does not answer your question) email:
>>> owner-sdlnews#sdl-forum.org
>>
>>
>> --
>> ======================================================================
>> 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 mailto:grabowski#cs.uni-goettingen.de
>> (Germany) http://www.swe.informatik.uni-goettingen.de
>> ======================================================================
>>
>
>
> ------------------------------------------------------------------------
> 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
> W.Skelton#SOLINET.com, www.SOLINET.com
>
>
>
> --End text from "William H. Skelton" <W.Skelton#SOLINET.com> to sdlnews ---
> For extra SDL Forum Society benefits join at
> <http://www.sdl-forum.org/Society/members.htm>
> For help, email "majordomo#sdl-forum.org" with the body of your email as:
> help
> or (iff this does not answer your question) email:
> owner-sdlnews#sdl-forum.org
-- ====================================================================== 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 mailto:grabowski#cs.uni-goettingen.de (Germany) http://www.swe.informatik.uni-goettingen.de ======================================================================--End text from Jens Grabowski <grabowski#informatik.uni-goettingen.de> to sdlnews --- For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT