Subject: Washington Issue 15 - Scope of Names

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 16:02:11 -0500

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: Jon Steer <[email-masked]>
Date: Mon, 15 Nov 1999 17:14:42 -0500

At 04:02 PM 11/15/99 -0500, Brian Rosen wrote:

I don't understand the rationale for this solution. It's flying in the face
of 40 years of language compilation experience.

In no compiled language that I know of, are keywords
allowed as identifiers.

Before this is accepted, someone should explain why
having to support token backtracking in a parser is
cheaper than having to be minimally careful about naming
privately defined packages,events etc..

Since MEGACO is supporting versioning, I don't understand
why "Problem with Solution 1" is a problem at all. Isn't
that one of the principal reasons for having versioning?

Or perhaps, there should be a public/private versioning
system in place so that privately defined extensions can
also be versioned.

jon

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Nov 1999 14:27:23 +0100

G'Day Brian,

I support Proposed solution 2.

Why? We have short tokens for A,C,O,M etc... Does this mean that a
package item cannot contain A,C,O,M because the parser/compiler might
get confused???

The names in property, signal, event, statistic is should of course be
unique within a single package.

Cheers, Christian

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 16 Nov 1999 14:45:03 -0500

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