Subject: Re: Washington Issue 15 - Scope of Names

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 08:36:05 -0500

Are you going to insist that parameter names be preceded
with package name:
Signals{foo/mySig{foo/parm1=2, foo/parm2="test", foo/parm4=true}}
Note that within the foo/mySig braces, every parameter HAS to
be the same package name!

However, if you allow it to be:
Signals{foo/mySig{parm1=2, parm2="test", parm4=true}}
then you are saying, when the parser knows the context,
it can disambiguate names in the symbol table.

If it can, then it can do so in several ways.

Names have scope folks.  If they have scope, you can use it.
Very old, very simple idea.

Having said that, I'm not really all that excited about
allowing package name to be optional in signals/events/properties
or statistics just because they happen to be unique for
a particular MG.  I do want the second of the two syntax
things above.

Brian

> -----Original Message-----
> From: Chuong Nguyen [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 4:30 PM
> To: [email-masked]
> Subject: Re: Washington Issue 15 - Scope of Names
>
>
> Briian
>
> I agree with Abdallah that pkgName should not be optional in
> the ABNF and
> from
> Megaco v12, Section 12.1:
> " .. and the ID of the item (which uniquely identifies the
> item in that
> package)."
>
> This implies that itemID is unique only in package and not
> across package.
> Therefore, pkgNamer is needed as a qualifier for itemID.
> It makes everything simpler to implement and one does not
> have to do extra
> work to see if there is any
> conflict in the itemID and tries to decide if pkgName is needed in the
> descriptor or not.
>
> Chuong
>
> On Tue, 16 Nov 1999 14:59:32 -0500, Brian Rosen
> <[email-masked]> wrote:
>
> >PackageNames were proposed as optional so that if there were
> >no name conflict you didn't have to use a fully qualified
> >name.  You know what packages a termination implements, so
> >any confusion is readily apparent.
> >
> >pkgdNames only appear in:
> >    TerminationState and LocalControl
> >    Events
> >    Signals
> >    Statistics
> >Within these descriptors, they are the only names
> >permitted (if you include names of parameters, and assume
> >that things like "KeepActive" are in fact automatically
> >declared parameters like SignalType).
> >
> >I think this means its really easy for the symbol table
> >to handle overlap of names spaces in any way we want to.
> >
> >It's vital to have a signal and an event have the same name
> >Once you have dealt with that, the rest is easy, I think.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: Abdallah Rayhan [mailto:[email-masked]]
> >> Sent: Tuesday, November 16, 1999 2:45 PM
> >> To: [email-masked]
> >> Subject: Re: Washington Issue 15 - Scope of Names
> >>
> >>
> >> What makes this issue interesting is the fact that packageName is
> >> optional in pkgdName. Therefore, even if you restrict packageName,
> >> you still have the ItemID which is not restricted by solution 1.
> >>
> >> The current ABNF says:
> >> pkgdName = [ (PackageName / "*") SLASH ] (ItemID / "*" )
> >>
> >> What would completely resolve this issue is making packageName
> >> mandatory. This will change the ABNF to:
> >>
> >> pkgdName = (PackageName / "*") SLASH  (ItemID / "*" )
> >>
> >> This resolves the ItemID and tokens problem. This is true because
> >> by the time pkgdName is due, the parser would know for sure that
> >> it is expected to parse pkgdName. As far as pkgdNames are
> >> considered they are strings with "/" in the middle. All programming
> >> languages allow tokens to be subtrings of variable names.
> >>
> >> But how about parameters which  are of the form
> >> NAME=VALUE. NAMEs should not be tokens IMO.
> >> However, I think it would hard to enforce at this time.
> >>
> >> As for overlapping, I am not sure I understand what you mean
> >> by that ! Is that within the same package ? Could you elaborate
> >> on it ?
> >>
> >> Abdallah Rayhan
> >>
> >> Brian Rosen wrote:
> >>
> >> > A number of issues were raised in the Washington meeting that
> >> > were "send to the list".  This is one of these issues, with the
> >> > problem and my suggested fix.
> >> >
> >> > Problem:
> >> > What is the scope of names?  Can package item (property, signal,
> >> > event, statistic) overlap Megaco protocol tokens and/or
> >> > other package items?
> >> >
> >> > Proposed Solution 1:
> >> > Overlap of names in property, signal, event, statistic is
> >> > allowed.  Overlap of package item with protocol tokens is
> >> > prohibited
> >> >
> >> > Problem with Solution 1:
> >> > Extensions to protocol may make a pre-existing package definition
> >> > invalid
> >> >
> >> > Proposal Number 2:
> >> > Overlap of names in property, signal, event, statistic is
> >> > allowed.  Overlap of package item with protocol tokens is
> >> > allowed.
> >> >
> >> > Brian
> >>
>

---

From: Chuong Nguyen <[email-masked]>
Date: Fri, 19 Nov 1999 08:30:30 -0600

> be the same package name!

Parameters should not be preceded by package name.  Just itemID which is
mySig in your example.

> it can disambiguate names in the symbol table.

This matches the ABNF so it is already the way you want it.

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: Ashok Khuntia <[email-masked]>
Date: Fri, 19 Nov 1999 08:56:57 -0600

The issue is not the parameters. It is the pkgdName. Whether package Id
in pkgdName is optional or not. For example:

a) Signals{foo/mySig{parm1=2, parm2="test", parm4=true}}

or

b) Signals{mySig{parm1=2, parm2="test", parm4=true}}

According to ABNF both are correct. However, both package Id and Item Id
should be mandatory.

Ashok Khuntia

Chuong Nguyen wrote:
> Parameters should not be preceded by package name.  Just itemID which
> is mySig in your example.
>
> >

--
  Alcatel USA                         Email:
[email-masked]
  1000 Coit Road Plano, Texas 75075   Phone: 972-477-7073
  **** The opinions expressed are not those of Alcatel USA ****

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 19 Nov 1999 10:23:41 -0500

Ashok,

I think Brian is not objecting to the mandatory rule, right Brian ?
The reason this issue is brought up is whether we should change
the ABNF to make package not optional. From what I gather in this
thread, the ABNF would carry this change in the next draft release.

IMO, as for parameters, unless someone comes with strong case,
we need not restrict it in this version of MEGACO.

Abdallah Rayhan