Conference azur::mcc

your suggestion is workable, and probably the easiest. It is what we did
on the "create domain <name> rule <name>" directive. In the IM PM change
the view to the rule view , update the toolbox to see the rule view of the
tools, and then select the rule icon. You will see what we did for
the different variants of the rule expression (rule formats).

As to doing variants on input, at this point in time, we still need to 
do some more definition work on how to make it work on input before we
can do any implementation.

	RE: .0,

	Just to clarify what is meant here, are you saying that one method to
work around this problem would be to implement a CREATE verb in my MM 
where some of the request arguments may be optional.  Thus, the PMs would 
generate a form to fill in where some arguments are optional fields and the MM
could then decide which attributes to use or not to use.  The drawback to this
method is that it "flattens" the attributes into the main object so it would
not be possible to differentiate between the attributes as easily.

	An alternate method would be to create a child object below the main
object to represent each of the variants that are required for the variant 
record.  In this way, each child object can be created as needed and new child
objects can be added later to represent the variant records.  Any feedback on
this technique?

	RE: .1,

>As to doing variants on input, at this point in time, we still need to 
>do some more definition work on how to make it work on input before we
>can do any implementation.

	Is this planned for V1.2 or V2.0?

	Carl

While variant records are in the entity model, I tend to use them cautiously.
Often an attribute of type record (with say 5 fields) could be replaced by
5 separate attributes. Similarly, an argument with 5 fields could be replaced
by 5 arguments. This is definately true if you want to manipulate the fields
individually.

Perhaps an example or two might help make this clearer?

Mark

	RE: .3,

	Thanks for the response, Mark!

	Is there any chance in the near future of this being in MCC?

>Perhaps an example or two might help make this clearer?

	Does anyone know of a good example of a variant record that is useful? 
It seems that depending on how you model your objects, it may not be too 
useful to use variant records.

	Carl

    currently the only uses that I have seen, and would consider "useful",
    are variant records that are used on output. As input arguments
    they can not be easily displayed to the user, or handled from the
    iconic map interface (and I don't believe they will be in 1.2 on input)
    but for output, they have their uses. DECnet phase V uses them
    frequently on output.
    

RE .5:
>
>    currently the only uses that I have seen, and would consider "useful",
>    are variant records that are used on output. As input arguments
>    they can not be easily displayed to the user, or handled from the
>    iconic map interface (and I don't believe they will be in 1.2 on input)
>    but for output, they have their uses. DECnet phase V uses them
>    frequently on output.
>    

I do not agree with your opinion.

When trying to modelize entities we frequently discover that variant records
are the best and shortest way to represent some data information.

It is real pain now to be obliged to find workarounds because we do not have
variant record support on input from the standard MCC PMs.

We (PNMP) were obliged to develop 2 PM applications to solve this problem :
we have to support two OSI defined settable attributes that are variant records
(CMISFilter and Weekly Scheduling Package).

There are at least two reason why variant record support on input should be
supported :

	1/ OSI uses frequently these kind of construction

	2/ Customer frequently ask for it (for what I am aware of...)

I am also not convinced that supporting variant records on input is technically
so difficult, but I am not a PM expert and so I will believe you...


Regards.

Pierre.

    I know that there are a few needs, but I would be interested (off-line)
    in knowing how we could generically support the input of variant
    records from both the command line and iconic map. So far we have found
    that the only solutions are expensive ones and would have come at the
    cost of some other more user visible functions.
    
    Don't get me wrong Pierre this is definitly not a dead issue. At some
    point in time we have to bite the bullet and make the investment in
    solving this. 
    

Re .7:
>
>    I know that there are a few needs, but I would be interested (off-line)
>    in knowing how we could generically support the input of variant
>    records from both the command line and iconic map. So far we have found
>    that the only solutions are expensive ones and would have come at the
>    cost of some other more user visible functions.

	Sorry, I have no magic idea to solve the problem. My impression
	was that the PMs do already very complicated decoding/encoding
	and I thougth that variant record support was not much more 
	complicated than other data type support. I should be wrong here...

>    Don't get me wrong Pierre this is definitly not a dead issue. At some
>    point in time we have to bite the bullet and make the investment in
>    solving this. 

	So everything is fine !

Thanks and regards.

Pierre.

    The problem with supporting a variant record is most dominant in the
    iconic interface. As things work today the IM PM is able to read the
    dictionary and define a "form" for each directive. There is currently
    no mechanism for allowing the user to specify the variant selector and
    they creating/requesting the appropriate variant fields.
    
    From the FCL the main problem comes from the structure of the parse
    tables. There are currently no constructs within the tables, or
    knowledge in the parser, for being able to handle dynamic input based
    on the variant selector. What we would need would be most likely a
    change to the parser to pull off the constructor (from paren to paren)
    and then instead of using the parse tables walk the construct by hand.
    Doing this means a reasonable amount of work. We would need to make
    sure that the parsing algorythmn would also work with the other modules
    that make use of the parser as well.
    
    I wish it was as cut and dry as a set or sequence, but it requires
    other design changes to be able to handle the input mechanisms.
    

Re .9:

I may be wrong, but ...

Couldn't you consider a variant record just as a plain simple record when
you input it, and do validation afterwards. Then after validation, issue
a meaningful error message, for example "field foo is not valid when
variant field bar value is so_an_so"...

You could apply the same strategy for the IMPM : build a "form" that contain
every field, and check after input.

I should be missing something....

Regards.

Pierre.