Subject: SDL-News: RE: [SDLTF-Members] SDL Task Force Reply to Keith Moss
From: Emmanuel Gaudin (emmanuel.gaudin#pragmadev.com)
Date: Mon Nov 24 2003 - 11:53:28 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 "Emmanuel Gaudin" <emmanuel.gaudin#pragmadev.com> to sdlnews -----
William,
I must say I have the same feeling than Keith here.
I told you in Stuttgart I wanted to actively participate in the task force
but then you told me the committee was settled and could not accept any one
else... You suggested I could join the task force and participate to the
discussions. So I sent a mail to info#SDL-Task-Force.org the 27th of August
in order to join the task force but I never received any reply. I actually
thought nothing was going on !
I am very surprised because this task force has been started to define a
sub-set of SDL so that it is supported by all tools; as far as I know, you
are the only tool vendor working on this. Am I right ?
Could you please clarify your position and would it be possible to have the
point of view or commitment from the other tool vendors ?
Regards,
Emmanuel
-- PragmaDev Emmanuel Gaudin Directeur tel: +33 1 42 74 15 38 fax: +33 1 42 74 15 58 http://www.pragmadev.com-----Original Message----- From: members-owner#sdl-task-force.org [mailto:members-owner#sdl-task-force.org]On Behalf Of William H. Skelton Sent: Friday, November 21, 2003 2:28 PM To: sdlnews#sdl-forum.org Cc: members#sdl-task-force.org Subject: [SDLTF-Members] SDL Task Force Reply to Keith Moss
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
--End text from "Emmanuel Gaudin" <emmanuel.gaudin#pragmadev.com> 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