Conference azur::mcc

.0>The argument could specify either the value of the element to be used as the 
.0>reference point, or the index of the element to be used as the reference 
.0>point. The latter seems simpler, as the datatype of the index can be fixed.
.0>We'd have to define whether the index of the first element is 0 or 1.
    
    Although I don't have any problem with your general approach, (it seems
    like a good approach to me) I do have one comment on using index
    numbers to define where to insert a new entry.  If you have the 
    possibility, however remote, of the sequence being changed between the 
    time you read the sequence and the time you add the new item, then you 
    run the risk of inserting the new item in the wrong place.
    
    Ways in which the sequence may change:
    	another manager adds an entry (or removes one, if this is allowed)
    	something (a service operation, not necessarily a management
    	 operation), removes the first item in the sequence.
    
    Consider the analogy of a VMS print queue - if you dealt with it by
    index number, rather than by entry number, you might get some
    surprising results
    
    Colin

RE: .1

>    	something (a service operation, not necessarily a management
>    	 operation), removes the first item in the sequence.

That is where the safety property saves us: if the management interface
can change the attribute via an ADD directive, then the entity isn't
allowed to change it via a service operation or anything else.

Nonetheless, you make a very valid point about specifying the point of
update as relative to an existing element. Since it is a read/modify/write
sequence with no locking, undefined results occur if two updaters overlap
their read/write operations.

Hmmm. So how ARE sequences supposed to be maintained?

I would NOT use ADD, and you cannot use ADD. Add as a modify type operation,
has no provision for entity specific arguments.

We avoided sequences in most attributes like the plague for exactly the
reasons you've discovered. They are a royal pain to manipulate.

If you have control over the definition of an ACL, change it to SET OF ACE
instead of SEQUENCE OF ACE. I think even VMS understands they did it wrong.

Otherwise, define actions Insert and Remove. Each takes a number (removes
the n-th one, or inserts after the n-th element), Insert also takes
an ACE. This is not very human friendly, but probably the best you can do.

		Mark

>We avoided sequences in most attributes like the plague for exactly the
>reasons you've discovered. They are a royal pain to manipulate.

Did you envision applications of sequences that wouldn't suffer from this
manipulation pain? Perhaps a brief description would help me change our
definitions so they fit better.

>If you have control over the definition of an ACL, change it to SET OF ACE
>instead of SEQUENCE OF ACE. I think even VMS understands they did it wrong.

We do have control of the defintion of ACL and other sequences. But in
each one, the order of the elements is significant, that's why they aren't
sets. So it is more than "using sets instead". It is re-designing the
data so it isn't order-sensitive.

One more for the folklore, eh, Mark?

>Did you envision applications of sequences that wouldn't suffer from this
>manipulation pain?
    
    Sequences are most often used when you don't manipulate the value, for
    example in a status attribute like the "Last Few Errors". Or when a
    whole sequence is entered as a unit, and not often "adjusted".
    
    Actually, what usually happens to complex sequences, especially
    sequences of records is that they are turned into child entities :-).
    That idea is somewhere in the data design section of the folklore.

RE: .5

>    Sequences are most often used when you don't manipulate the value, for
>    example in a status attribute like the "Last Few Errors". Or when a
>    whole sequence is entered as a unit, and not often "adjusted".

I was about to ask "if they aren't updated, then why can't they be a SET,
with no order?". Then I realized they datatype needs to be SEQUENCE so the
various components between the entity and the display device know the
order has to be preserved. So I'll buy the philosophy of sequences being
used where they aren't updated.

>    Actually, what usually happens to complex sequences, especially
>    sequences of records is that they are turned into child entities :-).
>    That idea is somewhere in the data design section of the folklore.

Indeed, and we have several entities that are defined simply to hold
information in an addressable fashion, information that would otherwise be
an attribute in the parent entity of datatype set.

But a sequence? How could that be modeled as a child entity, given that
entities don't have any defined order? Say you artificially created an
order with an integer identifier attribute. Inserting an instance into
that sequence would involve "renaming" all the instances that come after
it. yuk.

Given the difficulty of this, I must be trying to drive a square peg into
a round hole. Sounds like I should back off and re-examine the whole issue
of how we want to do per-instance access control.

Thanks

If you  can  redesign  it  then  great.   However,  you may (or may not!) be
comforted  that  the Phase V X.25 security modules use SEQUENCE OF to create
ACLs.

We thought about defining Insert and Remove directives for these but decided
not to bother.  People will probably edit these in the initialisation script
much more than they will change them on the fly.

I know  of  2  places where SEQUENCE OF is used in the Phase V architectures
(the  other  one is in MOP).  I always tell people not to use SEQUENCE OF if
at  all possible.  The other reason (apart from order) why a SEQUENCE may be
required  is  if duplicates are significant: SETs remove duplicates.  We did
have  a  SEQUENCE  OF  for  that  reason alone (the number of times an entry
appeared  gave  a "weight" to be associated with it) but we turned it into a
RECORD (with the weight as another field).

Graham

Thanks Graham.

We're looking at the DSSA spec to see where access control is likely to be
headed, although it is a fairly old draft and known to be changing. They
are defining ACLs as unordered sets with duplicates, so the SET datatype
looks like it will work. Instead of order they use a specific operation to
deny a principal a right that would otherwise be granted.

If we can make enough sense of it all we'll probably go with SET.

>They
>are defining ACLs as unordered sets with duplicates, so the SET datatype
>looks like it will work.

Did you  mean  "...*without*  duplicates..."?  If  not,  SET  won't  work as
duplicates are removed from SETs.

Graham