Re: MSC-News: Conditions in HMSC


Subject: Re: MSC-News: Conditions in HMSC
From: Oystein Haugen (etooha#eto.ericsson.se)
Date: Fri Jan 23 1998 - 13:54:23 GMT


The originator of this message is responsible for its content.
-----From Oystein Haugen <etooha#eto.ericsson.se> to mscnews -----

Jan Docekal wrote:

> Unfortunately I must disagree with the statement in the paragraph
> above.
> The chapter that treats HMSC starts like this:
>
> 5.5 High-level MSC (HMSC)
>
> High-level MSCs provide a means to graphically define how a set of
> MSCs
> can be combined. An HMSC is a directed graph where each node is either
> :
>
> - a start symbol (there is only one start symbol in each HMSC),
> - an end symbol,
> - an MSC reference,
> - a condition,
> - a connection point, or
> - a parallel frame.
>
> Both the Concrete Textual and Graphical grammar then states that the
> graph must start with an start symbol (if I interpret the {...} set
> operator correctly).
>
> Concrete textual grammar
>
> <msc expression> ::=
> <start> <node expression> *
> .....
>
> Concrete graphical grammar
>
> <mscexpr area> ::=
> { <start area> <node expression area>* <hmsc end
> area>*
> } set
>
> <start area> ::=
> <hmsc start symbol> is followed by { <alt op area>+ }
> set
> ...
>
> The proposed interpretation of fragmented HMSC's above would indeed
> give
> HMSC's the possibility to express (C++ styled) exceptions and a
> discussion in this direction should be encouraged (there have earlier
> been discussions of conditions in HMSC's as continuation points from
> referenced MSC's which have different exit conditions, and this would
> be
> a natural extension of this discussion). In my opinion the current
> version of Z.120 does not support your interpretation of HMSC
> fragmentation.
>
> Your interpretation of the semantic use of conditions fits (into my
> interpretation of) what Z.120 states
>
> Best regards
> - Jan Docekal
>

Dear Jan, Dagbjorn and other HMSC fans

It seems that Dagbjorn, Jan and I agree on the desirability to allow
fragments without start/end symbols in HMSC, but Jan and I have
different opinions about what the grammars allow. Below is my reason for
believing that the grammars may allow for the unattached fragments.

<msc expression> ::= <start> <node expression>*
<start> ::= not significant
<node expression> ::= <label name>:{<node> seq (<label name> {alt <label
name>}*) | end } <end>
<node> ::= (<msc ref expr>) | empty | <msc name> | <par expression> |
condition <condition name list> | connect

I cannot see anything here that connects the node expressions on top
level of the <msc expression> other than the names of the labels. A node
expression may very well start by a condition. Of course the total MSC
must always contain one start symbol, but this is not the issue.

In the graphical grammar, the situation is slightly more involved since
the connection lines combine symbols.
Firstly the top level production:

<mscexpr area> ::=
                { <start area> <node expression area>* <hmsc end area>*
} set

makes no assumption about how the individual areas are connected. That
is given in the productions using the meta-notation "is attached to".
Therefore I concluded that there are any unconnected set of <node
expression area>s, each of which may start with a <node area> which may
be an <hmsc condition area>. There is no definite requirement anywhere
that I could see that these <node expression area>s should be connected.

I appreciate the reactions from more people with intimate knowledge of
the MSC-96 grammars to make their opinions known.

Yours
Oystein Haugen

--
------------------------
Oystein Haugen, Ericsson as. , P.O. box 34, N-1361 Billingstad, Norway
Tel: +47 66 84 23 46 Fax: +47 66 84 19 15 E-mail: etooha#eto.ericsson.se

-----End text from Oystein Haugen <etooha#eto.ericsson.se> to mscnews ----- 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-mscnews#sdl-forum.org



This archive was generated by hypermail 2a23 : Wed Jun 19 2013 - 13:16:37 GMT