Subject: RE: MSC-News: Proposed changes to MSC'96 grammar to make it parsa ble. (more feedback wanted)
From: Jan Docekal (jan.docekal#telelogic.se)
Date: Mon May 18 1998 - 15:12:13 GMT
When I hoped that you would remain friend with me I assumed would imply
that you would agree with my propositions ;-)
As Oystein correctly pointed out my solution is not backward compatible,
but (in my opinion) my solution is more "readable" when MSC reference
expression becomes more complicated since both the parenthesis and the
keywords marks the end of an MSC's substitution. This example compares
the old grammar with my proposal
(r1 subst s1 by s2, s3 by s4 alt r2 subst s5 by s7) par (r3 subst s8
by empty alt r4)
(r1 (s1 := s2; s3 := s4) alt r2 (s5 := s7)) par (r3 (s8 := empty ) alt
If syntax highlighting is used I think the new proposal is still clearer
(see attachment in HTML).
Note that to achieve backward compatibility with the original grammar
that the parenthesis would only be added for timers and conditions in
the case they the substitutions do not contain commas i.e.
r1 subst msg s1 by s2, s3 by s4
r1 subst cond c1 by (c2, c3), (c5, c6) by c7
Unless, of course the possibility to optionally add parenthesis around
names in the original MSC'96 grammar. The changes will however not make
the grammars especially simple and the use of MSC reference expressions
might be confusing (when should/must I use parenthesis in
substitutions). I also suspect that "real life" substitutions might
become quite long, and in that case a terse notation is an advantage.
Unfortunately I must admit that Oysteins proposition has one (important)
merit! It is backward compatible! In my opinion it is not a problem to
break backward compatibility if there are no actual implementations
(tools, books, etc.). If on the other hand there exists implementations
to which backwards compatibility is crucial (e.g. nontrivial tools or
examples), I have no problem accepting Oysteins propositions.
Since some of you perhaps are not allowed to say WHY backward
compatibility is important (e.g. just finishing a tool etc.) it is
enough if you write if backward compatibility is important (but
naturally I AM interested in the reason).
Oystein also mentioned another important issue. The semantics of
substitutions. If any of You have any information/suggestions that might
change any of the two grammar proposals above, feel free to do so.
As I see it, we have two main alternatives:
1. I like the new way of writing substitutions. We should drop the
subst keyword and write all substitutions in parenthesis.
2a. Backward compatibility is crucial, add parentheses where needed.
Keep the subst keyword
2b. <Some other reason>. Keep the subst keyword.
PS I would also like to point out that I am only able to answer
questions regarding the Z.120 grammar and that I have no expertise in
the grammar of Z.105 and will thus admit no knowledge of that sort.
From: Oystein Haugen [SMTP:etooha#eto.ericsson.se]
Sent: den 15 maj 1998 11:19
To: Jan Docekal
Subject: Re: MSC-news: Proposed changes to MSC'96 grammar
to make it parsable.
The originator of this message is responsible for its content.
-----From Oystein Haugen <etooha#eto.ericsson.se> to mscnews
Jan Docekal wrote:
> The originator of this message is responsible for its content.
> -----From Jan Docekal <jan.docekal#telelogic.se> to mscnews
> Dear MSC friends,
> I hope that you will remain friends after you have read this
Dear JanYou are still my friend after this, and I believe your
make MSC an even more friendly language.
> Problem 1: Substitutions
> The problem with this grammar is that an LALR(1) parser (and
> human reader) has a problem with deciding when substitution
> that may contain commas end (This is due to the fact that
> rules may contain commas and that <substitution list>s are
> commas. Consider the following substitution example:
When it comes to substitutions, we have the following
grammar is not properly parsable as pointed out above, and it
2. The formal semantics of substitution is still not finalized.
the current Annex B just standardized omits substitution)
3. The practical writing of substitutions is space consuming
to the use of keywords "subst" and "by".
> Proposed solution:
> The keyword subst should be dropped. The following syntax
> for substitutions (examples analogous to the two substitutions
> reference R (a1, b1, c1 := a2, b2, c2; d1, e1, f1:= d2, e2,
> reference R (a1, b1, c1 := a2, b2, c2, d1, e1; f1:= d2, e2,
> No grammar will be given for this syntax proposal at this
> the syntax might be changed base on Your feedback. If the
> accepted by the MSC community, a grammar will naturally be
I do not suspect that the work on the semantics of substitution
affect this discussion, but in principle the semantic
result in minor modification desires as well.There is no doubt
should make the grammar parsable, but we need not do this as
as Jan suggests. As far as I can see, parentheses can do the
and we may be backwards compatible with the original MSC-96,
that the example would read:
reference R subst (a1,b1,c1) by (a2, b2,c2), (d1,e1,f1) by
The grammar is trivial to update.
One problem with my solution is that the size of the clause will
increase and not decrease. Still I think that the backward
and the general style of MSC point in the direction of using
> Problem 2: Event "labels"
> Proposed solution:
Do whatever you find practical since it is not seen by real
Oystein Haugen, Ericsson as. , P.O. box 34, N-1361 Billingstad,
Tel: +47 66 84 23 46 Fax: +47 66 84 19 15 E-mail:
-----End text from Oystein Haugen <etooha#eto.ericsson.se> to
For help, email "majordomo#sdl-forum.org" with the body of your
or (iff this does not answer your question) email:
This archive was generated by hypermail 2a23 : Wed Jun 19 2013 - 13:16:38 GMT