Subject: Re: Washington Issue 15 - Scope of Names

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Nov 1999 14:59:32 -0500

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: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Nov 1999 10:33:12 -0500

Something must be interfering with reception around here.

If you allow the parameter names without the package names in
the symbol table, and there are two packages with the same
parameter name, then you have an implementation issue.  There
is no protocol ambiguity, but your symbol table has to handle
multiple entries with the same name.  You solve this with scope.
You allow multiple names in the symbol table, and you resolve
the ambiguities with scope.

I'm still not really seriously opposed to requiring package
names in pkgdName.  It WILL have a noticeable effect on the
average length of messages.

Brian

> From: Ashok Khuntia [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 9:57 AM
> 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:
> >
> > "Rosen, Brian" wrote:
> >
> > > 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!
> > >
> >
> > Parameters should not be preceded by package name.  Just
> itemID which
> > is mySig in your example.
> >
> > >
> > > 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.
> > >
> >
> > This matches the ABNF so it is already the way you want it.
> >
> > >
> > > 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
> > >
> > > > From: Chuong Nguyen [mailto:[email-masked]]
> > > > Sent: Thursday, November 18, 1999 4:30 PM
> > > > 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:
> > > >
> > > > >> What makes this issue interesting is the fact that
> packageName
> > > is
> > --
> >   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 ****
> >
> >
>
> --
>   Alcatel USA                         Email:
> [email-masked]
>   1000 Coit Road Plano, Texas 75075   Phone: 972-477-7073
>   **** The opinions expressed are not those of Alcatel USA ****
>