Subject: SDL-News: Fwd: [SDLTF-Members] SDL Task Force Reply to Keith Moss
From: William H. Skelton (W.Skelton#SOLINET.com)
Date: Sun Nov 23 2003 - 13:45:53 GMT
>Date: Fri, 21 Nov 2003 14:28:24 +0100
>To: sdlnews#sdl-forum.org
>From: "William H. Skelton" <W.Skelton#SOLINET.com>
>Subject: [SDLTF-Members] SDL Task Force Reply to Keith Moss
>Cc: members#sdl-task-force.org
>
>Dear Keith,
>
>Thank you for raising this issue, which I would like to comment on.
>
>The SDL Task Force has been active, but as I mentioned before, the main
>contribution has been from the committee (Alkis Yiannakoulias, Qing Li,
>Vangeli Kollias, Andreas Prinz & myself).
>
>There have been meetings with more active members, such as the Daniel
>Amyot & Alan Williams, who as you probably know are also hosting the SAM
>workshop next year, Alcatel & Motorola, but the results have been edited
>into the draft specification without details of the discussions themselves.
>
>I am sorry if you have the impression that this has been 'behind closed
>doors'.
>
>There is not an 'inner committee', but a committee of people, who are
>funding this activity themselves without external support. The
>publication of results is voluntary and intended to help the further
>development of SDL.
>
>The draft specification, which is published at www.SDL-Task-Force.org, is
>actually not even a draft, but a working form of the planned
>draft. Comments are invited for the further evolution.
>
>If you feel there has not been much visible communication on this subject,
>I warmly welcome you to address your comments to the task force. I have
>inserted my personal opinion at several points below, but suggest the
>discussion should continue on the task force mail exploder. :-)
>
>Just checking now with my colleagues, it seems you use two email addresses
>(AOL & IEEE), but only the IEEE address is registered with the mail
>server. This may lead to your emails not being accepted.
>
>William
>
>>From: KEMoss6#aol.com
>>Date: Tue, 18 Nov 2003 04:55:14 EST
>>Subject: [sdl-forum] SDL-news: task force
>>To: sdlnews#sdl-forum.org
>>
>>Dear All
>>
>>I was prompted to write this email after I had read the email exchange
>>between Rick and William. Until then even though I have signed up to be a
>>member of
>>the task force I was not aware of any activity even though I had twice
>>corresponded with William on just that subject.
>>
>>As far as I'm concerned the inner committee appears to be conducting affairs
>>behind closed doors. However I have now read the latest documentation the
>>draft specification and I have a few observations.
>>
>>I feel that the specification needs to be presented in graphical format as
>>this is much easier to understand especially for new users and for
>>especially
>>for users who are programming experts. A diagram helps immensely to
>>explain an
>>idea and can be just as rigorous in definition. Many of the paragraphs in
>>the
>>document could be reduced if only the relevant diagram were present.
>
>I'm all for simplification, but to be honest, I think the text is
>necessary and have tried hard for it to be easy to understand. Certainly
>compared to the ITU-T specifications, I think this criticism is a bit
>harsh. :-)
>
>If you would like to make a suggestion how to represent these concepts
>graphically, I would be glad to take it further.
>
>>I feel that SDl should be universal and separate domains of interest are
>>only
>>likely to lead to fragmentation of the SDL forum.
>
>There is no fragmentation, participation is open to anyone from the SDL Forum.
>
>>There is a section "State-Event matrix" which mentions constraints without
>>ever explaining what a constraint might be. If the subset is ever to be
>>considered a simplification then there needs to be less abstract ideas
>>incorporated.
>
>You're right, constraints needs explaining. They are a generalisation
>taken from testing concepts, where one can see even specifying only the
>expected signal name can be considered to be a constraint on the received
>signal. In testing concepts one sees the constraints as mainly to do with
>the expected values for parameters, but it can be generalised to be
>anything to do with the signal, also the gate it arrives on.
>
>>As I understand one of the objectives is to make SDL more universally used
>>and this can only be achieved if the initial contact is easy to assimilate.
>>
>>I also feel that the "Save" construct is much easier to understand than many
>>of ideas to be incorporated. I don't buy the idea that it complicates
>>matters.
>>If a queue has to be designed to cover the loss of the "save" construct, the
>>queue will have to managed.
>
>The point is explained actually in some detail; the use of a queue is an
>application related issue, not a system issue. If you want a queue,
>declare it and use it with add/remove functions where and when you need
>it. Utilising an implicit system feature of buffering on a gate, because
>'the mechanism is probably there anyway', hides the application related
>functionality and makes a system less readable.
>
>Some people have said it makes a system more readable, even though the
>principle is actually deeper than that. To make a decision on this, we
>concluded it is not needed for implementing the 'simplest, useful' SDL
>systems, and it was removed.
>
>
>>Regards Keith Moss (Task force member?)
>>
>>ps I have sent this to the SDL news as I appear to have no priviledges to
>>send to the task force even though I'm supposed to be a member
>
>
>------------------------------------------------------------------------
>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
------------------------------------------------------------------------
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
Date: Fri, 21 Nov 2003 14:28:24 +0100
To: sdlnews#sdl-forum.org
From: "William H. Skelton" <W.Skelton#SOLINET.com>
Subject: [SDLTF-Members] SDL Task Force Reply to Keith Moss
Cc: members#sdl-task-force.org
Dear Keith,
Thank you for raising this issue, which I would like to comment on.
The SDL Task Force has been active, but as I mentioned before, the main contribution has been from the committee (Alkis Yiannakoulias, Qing Li, Vangeli Kollias, Andreas Prinz & myself).
There have been meetings with more active members, such as the Daniel Amyot & Alan Williams, who as you probably know are also hosting the SAM workshop next year, Alcatel & Motorola, but the results have been edited into the draft specification without details of the discussions themselves.
I am sorry if you have the impression that this has been 'behind closed doors'.
There is not an 'inner committee', but a committee of people, who are funding this activity themselves without external support. The publication of results is voluntary and intended to help the further development of SDL.
The draft specification, which is published at www.SDL-Task-Force.org [NOTE: June 2013 - link no longer valid], is actually not even a draft, but a working form of the planned draft. Comments are invited for the further evolution.
If you feel there has not been much visible communication on this subject, I warmly welcome you to address your comments to the task force. I have inserted my personal opinion at several points below, but suggest the discussion should continue on the task force mail exploder. :-)
Just checking now with my colleagues, it seems you use two email addresses (AOL & IEEE), but only the IEEE address is registered with the mail server. This may lead to your emails not being accepted.
William
From: KEMoss6#aol.com
Date: Tue, 18 Nov 2003 04:55:14 EST
Subject: [sdl-forum] SDL-News: task force
To: sdlnews#sdl-forum.org
Dear All
I was prompted to write this email after I had read the email exchange
between Rick and William. Until then even though I have signed up to be a member of
the task force I was not aware of any activity even though I had twice
corresponded with William on just that subject.
As far as I'm concerned the inner committee appears to be conducting affairs
behind closed doors. However I have now read the latest documentation the
draft specification and I have a few observations.
I feel that the specification needs to be presented in graphical format as
this is much easier to understand especially for new users and for especially
for users who are programming experts. A diagram helps immensely to explain an
idea and can be just as rigorous in definition. Many of the paragraphs in the
document could be reduced if only the relevant diagram were present.
I'm all for simplification, but to be honest, I think the text is necessary and have tried hard for it to be easy to understand. Certainly compared to the ITU-T specifications, I think this criticism is a bit harsh. :-)
If you would like to make a suggestion how to represent these concepts graphically, I would be glad to take it further.
I feel that SDl should be universal and separate domains of interest are only
likely to lead to fragmentation of the SDL forum.
There is a section "State-Event matrix" which mentions constraints without
ever explaining what a constraint might be. If the subset is ever to be
considered a simplification then there needs to be less abstract ideas incorporated.
As I understand one of the objectives is to make SDL more universally used
and this can only be achieved if the initial contact is easy to assimilate.
I also feel that the "Save" construct is much easier to understand than many
of ideas to be incorporated. I don't buy the idea that it complicates matters.
If a queue has to be designed to cover the loss of the "save" construct, the
queue will have to managed.
Regards Keith Moss (Task force member?)
ps I have sent this to the SDL news as I appear to have no priviledges to send to the task force even though I'm supposed to be a member
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT