Conference azur::mcc

Hence, the Type attribute is a characteristic, and the Capability attribute
is a Status. And there's the rub: the SRM says the attribute referred to
by the DEPENDS ON clause has to be a characteristic.

>The "Selector Attribute" not only has to be a characteristic, it has
>to be an enumeration.  So, the solution looks something like:  Define
>an extra characteristic attribute of type enumeration to use as the selector.
>The value of this characteristic is derived from the value of the status
>attribute.  The selector characteristic probably need not be visible to the
>end user--it ought to be redundant information.

I could make Capability a non-settable characteristic, but then we'd have
a characteristic attribute being set by the entity, which is a violation
of the entity model. If I leave Capability as a settable characteristic
then its value could become out of sync with that of Type.

Is there any "right" solution?

>One of the reasons for the restictions on selector attributes (they must
>be characteristics, enumerations, predictable) is to reduce the number of
>times the entity must be queried to determine which variant it is (one show
>request per attribute partition).  The above workaround adds back in 
>a request for status attributes to determine the variant--some code has to
>update the value of the selector attribute, and that code will be
>the AM that speaks the entity's language.  If you can find something 
>better, do it.  (and spread the word) I would suggest that if there is a 
>legitimate way to determine the variant from already defined characteristics, 
>that should be done instead.

>Another thought--how often is the child entity going to switch
>from one variant to another? Can the variant be determined once, at
>child instantiation?  The work to maintain an extra enumeration characteristic
>must be done with the same frequency.

>I don't believe that all of the restrictions on selector attributes are
>permanent. I hope that if you have an idea on how to alter these restrictions
>and still keep the work of determining the variant of an entity to a 
>minimum, you'll tell us.

RE: .1 TOOK::KOHLS "Ruth Kohls"

Thanks for the reply, Ruth.

>The "Selector Attribute" not only has to be a characteristic, it has
>to be an enumeration.  So, the solution looks something like:  Define
>an extra characteristic attribute of type enumeration to use as the selector.
>The value of this characteristic is derived from the value of the status
>attribute.  The selector characteristic probably need not be visible to the
>end user--it ought to be redundant information.

I proposed this solution in the base note. It has a flaw in that the
selector attribute is a characteristic that is being set by the entity,
a violation of the Entity Model.

>Another thought--how often is the child entity going to switch
>from one variant to another? Can the variant be determined once, at
>child instantiation?  The work to maintain an extra enumeration characteristic
>must be done with the same frequency.

The variant is selected at creation and never changed. For that reason I
would rather have the selector a non-settable status attribute. I would
have the variant specified as an argument to the create directive, and 
stored in the readonly selector. Perhaps a future version could consider
that.

>One of the reasons for the restictions on selector attributes (they must
>be characteristics, enumerations, predictable) is to reduce the number of
>times the entity must be queried to determine which variant it is (one show
>request per attribute partition).  The above workaround adds back in 

That presumes (I think) that only characteristic attributes can have the
DEPENDS ON clause. If so that isn't brought out in the SRM. I'm planning on
using it on both characteristic and status attributes, and probably a 
counter as well. Will that fail?

The T1.1.0 MSL compiler won't parse the variant attribute, although it is 
happy with the selector. I've placed them both in the Characteristics
partition until I decide on the architectural morality issue.

TYPE
    CartCapabilities = 52 (Base Cartridge = 1, Compound Cartridge = 2,
                           Temporary Binding = 4, Permanent Binding = 8,
                           Not Loadable = 16, Loadable = 32);
 
         ATTRIBUTE Capability = 123 : CartCapabilities
           (* Enumerated value loaded from the referenced
              Cartridge Type instance. *)
           SYMBOL = ATTR_CAPABILITY,
           ACCESS = NONSETTABLE
         END ATTRIBUTE Capability;

         ATTRIBUTE Sides = 9 : Unsigned16
           (* For a base cartridge only, the number of cartridge
              sides. *)
           DEPENDS ON = Capability IN SET (Base Cartridge),
           SYMBOL = ATTR_SIDES
         END ATTRIBUTE Sides;
 

> put double quotes around the Depends On expression, e.g.
>           DEPENDS ON = "Capability IN SET (Base Cartridge)",
>
>I think this is shown on p 122 (sec. 7.5.1.3) of version 1.1 of the SRM,
>vol. 1.
>If that doesn't work, send me mail and include any error message or log msl 
>supplies.

>re .1, .2; I want to make a quibbling distinction between "depending on" 
>a non-displayed characteristic attribute value derived *in the AM* from a 
>predictable value obtained from the entity and "depending on" a visible
>non-characteristic something,  directly.  I'd prefer you do what makes most 
>sense to you.  Perhaps if you haven't talked with Kathrin Winkler already,
>it might be worth your time.  She is dealing with some similar problems.

>The list of things which may be dependent (have a DEPENDS ON) is also given 
>on p 122.  I believe the list omits event arguments.
>in .2 I was referring to how many times the entity itself must be asked
>for the values of SELECTORs (the dependED on).  The number of such queries
>must be minimized.

Ruth

RE: .5

Thank you again Ruth, the double quotes got it through the compile. One of
these days I'll learn to read BNF. :-)  I just found the proper syntax is also
shown in the examples on page 150, so put me down for another "duh" point.

I'll look into the other info you mentioned.

To be very clear why I say my quibble in .5 is a quibble--  defining the
extra characteristic in the AM  does not change the conflict with the entity
model here.  The entity must be asked the value of the status to determine
the value of the characteristic, meaning the entity is still turning this
knob. (In this case, it appears that the status attribute gets altered once, 
making the it have the safety property.)  The characteristic attribute adds 
some work to the AM as well (How much depends on how "safe" the status 
attribute is).  All this route allows is that the status attribute can be
seen as a status attribute, if that is what it should be.  Since the extra
characteristic need not be visible to the end user, if we should change the
restrictions on selector attributes so that status attributes are allowed to be
"depended on", the extra characteristic could vanish completely and not cause
re-arrangement of visible attributes into different partitions.

Ruth

If in fact Sides and Components depend only on Capability, and Capability is
something that is obtained from the Cartridge Type entity, why not make the
DEPENDS ON attributes belong to Cartridge Type?

                    Media Library
                    /            \
           Cartridge Type        Branch Library
             attr Capability              \
              (base or compound)       Cartridge
             attr Sides                  attr Type
              depends on Capability = base
             attr Components
              depends on Capability = compound

-Lance-

>If in fact Sides and Components depend only on Capability, and Capability is
>something that is obtained from the Cartridge Type entity, why not make the
>DEPENDS ON attributes belong to Cartridge Type?

That would be nice, but the values of Sides and Components relate to
children of this Cartridge, not to all Cartridges of this Cartridge Type.

    Hmmm. DEPENDS ON won't accept a selector of type Boolean. Isn't Boolean
    just a special case of enumeration, a shorthand for
    
    	TYPE Boolean = nn (False = 0, True = 1);
    
    Would you consider making Boolean a valid selector datatype?
    

    Boolean should be legal.  I will check to see if it supported, and if
    it isn't, I will QAR it.
    
    What was the exact syntax that you used?
    
    I would expect something like:
    
        DEPENDS ON = "foo = TRUE" 
    
    (where foo is a boolean characteristics attribute) to work.
    
    -Matt.

RE: .11

The exact syntax was:

	DEPENDS ON = "Scratch = True"

where
      CHARACTERISTIC ATTRIBUTES
	ATTRIBUTE Scratch : Boolean

%MCCMSL-E-INVVARATTRDT, The variant selector attribute "scratch",
         in the DEPENDS ON statement is not an enumeration datatype

    Richard,
    
    I have just read the SRM.  It states that datatype of the
    characteristic attribute can >>only<< be enumeration.  And,
    furthermore, the Boolean datatype is not a special case of the
    enumeration datatype, e.g., different operations can be performed on it
    (for example Logical operations are valid for Boolean, not for
    Enumeration), it has a different size, etc.  The MSL translator took
    the SRM much more literally than I thought it did (which is probably
    goodness).  Perhaps we can relax the restriction for V1.2, we'll have
    to investigate that.
    
    You should be able to do what you want by defining an enumeration
    datatype whose two values are "True" and "False", i.e.,
    
    TYPE
    	MyBoolean = nn ( False = 0, True = 1);
    
    (This would restrict the operations, change the size, etc. of the
    datatype.)
    
    -Matt.

The V1.1 SRM says the depends on can be applied to a directive, as long as
the selector is a characteristic of the same entity. But the MSL compiler
says no. If I comment-out the DEPENDS ON the whole spec compiles.

TYPE
    TempBoolean = 31 (False = 0, True = 1);
 
         ATTRIBUTE Scratch = 98 : TempBoolean
           (* True iff this is a scratch Collection. If true collection
              may contain only Scratch or Preassigned Media objects.
              If false this collection may contain Assigned or Released
              Media objects. Cartridge Sides in other states have a
              zero Collection Identifier and hence do not have a Media
              alias in any Collection.

              This attribute is not settable from the management
              interface, and hence should be in the Status partition,
              below. But it is the selector for a DEPENDS ON clause,
              and must be a Characteristic. *)
           ACCESS = NONSETABLE,
           SYMBOL = ATTR_SCRATCH
         END ATTRIBUTE Scratch;

       DIRECTIVE Assign = 136 :
         (* Assigns an object from this Scratch Collection and names it
            with the specified media name. *)
          DIRECTIVE-TYPE = ACTION,
          DEPENDS ON = "Scratch = True",
          SYMBOL = VERB_ASSIGN,

%MCCMSL-E-TEXT, "DEPENDS ON = " Scratch = True " " was not parsed

Using the mcs version of msl, I got Directive "DEPENDS ON"s work with your
TempBoolean enumeration, with no problem.  I can't do much more without looking
at more of your ms. (And I admit I want to see as little as possible of it!)
Please be sure the selector attribute (the one your directive "depends on") is
defined in the correct place.  Watch your commas, too.   If you can't see a 
problem, create an .ms with the smallest amount of .ms definition that fails
and mail it to me, at TOOK::KOHLS.

Ruth

>     You should be able to do what you want by defining an enumeration
>     datatype whose two values are "True" and "False", i.e.,
>     
>     TYPE
>     	MyBoolean = nn ( False = 0, True = 1);
>     
>     (This would restrict the operations, change the size, etc. of the
>     datatype.)

Note that  this also changes the datatype of the attribute.  For example the
Phase  V AM will encode this in CMIP as an INTEGER not as a BOOLEAN.  In the
case  of  a  Phase  V  entity this difference is crucial and would cause the
operation to be rejected.

Graham

RE: .17

>Did you type this in, or extract it from your MS, and did you include
>the latest MSL error log?  (am I mistaken??  sure wouldn't be the first time!)

I cut it from an editor window and pasted it to the DECwindows Notes window.
I just checked, and the .ms source file does have "NONSETABLE".

Worth noting is that other attributes in the same entity also have a
DEPENDS ON referencing the Scratch attribute, no problem with them. Just the
one on the directive.

So I did my last resort when apparently good MSL won't parse: I deleted the
line and retyped the DEPENDS ON clause. The whole spec now compiles. That
implies two things:

	1. The MSL compiler will take both NONSETABLE and NONSETTABLE

	2. The MSL compiler was seeing somthing other than a space where
           my editor (Emacs) was showing only whitespace. Emacs shows
           any non-printing char other than space or tab, and wasn't
	   showing anything.

I'll change the ACCESS = NONSETABLE to make it conform to the SRM.

Does the MSL compiler treat tabs and spaces as whitespace?

The reply you saw and I later deleted was wrong.  MSL will take both
NONSETABLE and NONSETTABLE.  MY mistake was capitalization.  Once I got
that right I couldn't reproduce the error with your fragments no matter how 
exactly I tried.  (I was grafting on the rest of a directive from my good
msl with it's requests, responses, and exceptions.)

White space is ignored by MSL.  It is defined as : space, horizontal tab, eol,
nel (newline), cr, lf, or ff.

Matt tells me he looked through the SRM for references to Depends On in
directives and saw several different placements for it in relation to the
other "properties" of Directives.  Your Depends on was placed correctly.
I will check the SRM and QAR the references to Directive Depends Ons as 
necessary.  

The amount of text MSL rejects when it encounters a Syntax error (MSL-E-TEXT)
is variable, depending on the way the set of definitions was implemented.
If you get an entire block of definition text, the syntax error could be 
anywhere in it.  With a one-line rejection, you have less to work through.

I have no way of guessing what glitch disappeared when you re-typed the line.

I'm glad it went away, though.

>That presumes (I think) that only characteristic attributes can have the
>DEPENDS ON clause. If so that isn't brought out in the SRM. I'm planning on
>using it on both characteristic and status attributes, and probably a 
>counter as well. Will that fail?

  Nope.  You can have DEPENDS ON under any attribute.  The only restriction
  is that the attribute used in the DEPENDS ON is defined under the 
  CHARACTERISTICS partition and it has a datatype of ENUMERATION. 

/Jim

    Could someone shed some light on V1.2's functionality of
    DEPENDS ON. Will the DEPENDS ON attribute still have to be a 
    Characteristic? More importantly, will it be possible for it 
    to be a Boolean rather than Enumeration?

    -John

>    Could someone shed some light on V1.2's functionality of
>    DEPENDS ON. Will the DEPENDS ON attribute still have to be a 
>    Characteristic? More importantly, will it be possible for it 
>    to be a Boolean rather than Enumeration?

Several suggested  changes for DEPENDS ON  were low priority
for v1.2, and so fell off the list of work for v1.2.

The attribute "Depended on" will still have to be a Characteristic
and still must be an Enumeration.  (The workaround for Boolean is still to 
define a private enumeration "boolean".)

You can submit an eco proposal to TOOK::MASG, outlining the changes to
the architecture (SRM) required for additions or changes to the way DEPENDS ON
works.  You may find that there are conceptual problems with allowing 
the "depended on" attribute to be a status. (I remember that Colin Strutt
and Pete Savage had objections, but I forget what they were.)  

Ruth K.