Conference azur::mcc

   The next version of the iconic map sets the first letter of 
the directives and attribute partitions/groups in the  Operations 
pull down menu to be a capital letter.  It will lower case the rest.   

This is done regardless of the presentation name stored.  We do this to follow 
decwindow style guide conventions.  

   Maybe we should be doing it for the attribute names to? 

/Jim

>   The next version of the iconic map sets the first letter of 
>the directives and attribute partitions/groups in the  Operations 
>pull down menu to be a capital letter.  It will lower case the rest.   

Don't do that.  There are two reasons:

1) Due  to a restriction in the NCL parsing rules, directive names (at least
for  EMA  entities)  have to be a single word.  Some directives, however are
logically  two words (e.g.  StopLoop) and the capitalisation is an important
part  of the user interface ("Hey, Bud, what's this Sto-ploop directive this
entity  supports?",  "look  you idiot, that's the Stoplo-op directive, don't
you know nuthin?").

2) Some  class,  directive,  attribute,  argument  or enumarated value names
contain acronyms or abbreviations.  These should be in all capitals.

The capitalisation  is an important part of the user interface for keywords.
You should use the capitalisation provided in the MSL file for all keywords.
If  that  conflicts  with the DECwindows style guide then you should suggest
changing the MSLs, not override them.

The restriction  in  the  SRM  should  be  removed.  At most, the SRM should
contain a guideline.  And it should be identical for all keywords.

Graham

re: .-1

I will qar srm to change secton 7.5.1.3 discussing Keywords to state
that the keyword should be typed in precicely how the user expects to see it.

This is what the version x1.0 does.  Notice how ugly the operations pulldowm 
menu looks when a node4 is selected.  Some are in lower, some in upper case.


/Jim

    Re: .2
    NCL may be restricted to single word keywords, but MCC has already
    "broken" that restriction.
    As we need to add significant numbers of (Director supplied) functions,
    we would quickly run out of sensible words, and runningwordstogether
    doesnotseemtobeaverygoodideaforhumanbeings.
    
    So we decided to implement multiword commands - Mark Sylor warned us
    of the dire consequences, but Len & I agreed it was sorta necessary.
    
    Colin

Re: .4.   Interesting.  I certainly convinced myself, a while ago, that this
lead to ambiguous syntax.  I'm certainly willing to believe I was wrong.

Are you changing the verbs which DNA is defining (StartLoop, etc.)?

Graham

    
    It CAN lead to ambiguous syntax, for that reason we had to tighten
    the rules around naming multiple keyword verbs. We get around most
    of the ambiguous problems by simply NOT allowing the user to define
    verbs that are substrings of other verbs (ex: if you have a verb
    SHOW you couldn't have a verb SHOW COUNTERS, the same is true of
    a verb SHOW and trying to have a verb called SHOWCOUNTERS, these
    would be considered ambiguous by the new rules).
    
    As to renaming the DNA directives, in the V1.0 system at least,
    these verbs are as defined (startloop, stoploop, are one word).

And as Jill pointed out, this test that one verb cannot be an initial 
string of another is the requirement. However, this depends on a Global
registration table of all verbs (a registration that checks all verbs on
all entities). The StartLoop example is a good one here. Defining a Start Loop
command in entity A means that no other entity can define a Start command.
Of course this will pose an interesting problem, as there already exists
a defined Start verb. How then does MCC resolve the ambiguity of Start vs. 
Start Loop?

As should be well known now, this is why the NCL architecture made a 
different choice. We chose to make verbs have a local scope within an Entity,
not a global scope spanning entities. While we gave up multiword verbs, (note
we allow multi-word keywords in general), this allowed a fairly simple NCL
parser.

As I and others have pointed out many times, life would be much simpler if MCC's
TRM conformed to the NCL syntax. This is necessary before MCC can "replace" NCL
on the VMS kit (a goal of many people). MCC needs a few additional prepositional
qualifiers not defined in the NCL basic director spec*, but those can 
be accomodated straightforwardly.

					Mark

* It's important to remember that the NCL spec defines 2 things, a syntax for a
language (NCL) and the functions providied by a basic director (NCL the progam).
MCC can implement the former, while providing different (hopefully 
more powerful) functions.

PS, if people are absolutely convinced that we need multiword directive names
(verb + noun) then I know a way to do it that doesn't introduce 
such severe parsing problems, and would not require a global verb registry.
Given a directive name such as Start Loop, we observe that the directive name 
consists of a verb (Start) and a verb modifier (in this case a noun (Loop)). 
The command syntax would be

<verb> <entity> <verb-modifier> <arg-list>

or in this example

Start Node foo MOP Loop <args>

The only requirement here is that the word Loop must not conflict with a 
sub-class name, or if Start alone is a valid operation name, that none of
its arguments begin with the word Loop. Personally, I can live without them.

    
    Since the multi-keyword required the uniqueness rules be enforced
    for the parser to work. We have added this checking to the Parse
    Table Builder (PTB) tool. If you enter a verb that conflicts with
    another in most, if not all cases, PTB should be capable of detecting
    and reporting the error.
    
    

    Sorry I gotta side with Mark on this one (surprise).  Command line
    users are quite used to typing underscores as separators. And  for the
    iconic interface, who cares? The user isn't going to be typing verbs
    anyway.
    
    It makes the parser a mess and makes it less likely we will ever  get
    it replaced with something more straightforward.
    
    It also makes schemes for parsing straight out of the dictionary (the
    long awaited elimination of PTB) much more difficult (and hence longer
    in coming).   With one-word verbs you don't need an inverted dictionary
    to parse since you can assume the first word is a verb and start
    parsing with the entity which would be easily implemented against the
    current dict.
    
    Get rid of them before it's too late.