Operational attributes (was"Re: [provision] Standard Schema draft 4 - big issues.")

["Gary.P.Cole" <Gary.P.Cole@Sun.COM>]

Kent Spaulding wrote:

I have yet to read the latest revision, but I'm chime in anyway.

On 5/6/07 6:08 PM, "Gary.P.Cole" <Gary.P.Cole@Sun.COM> wrote:

1) Should the Schema have operational attributes that duplicate
standard capabilities?

NOTE: Jeff Bohren dislikes this, but operational attributes allow a single
request to do much more than it otherwise could (e.g., create a Person in a
disabled state or create an Account with a pre-expired password).
    

Perhaps I misunderstand, but I don't generally like data that is 'active'
either... At least for over-the-wire protocols.  The idealist says all
side-effects are bad.
 
Hmmm, maybe I need some clarification... Am I to understand that if I use
'disabled' as an attribute in the schema to represent disabled accounts, and
I do a 'modify' that changes 'disabled' for some account from false to true,
I've just enabled the account. I suppose that's not exactly a side-effect...
And would be what one might expect.  Besides, to avoid this, we'd have to
have the notion of read-only (of informational-only) attributes that can't
be set.  We'd have to complain (or ignore that attribute) in the modify.

Having said all that, I suppose, since we went to all that trouble to define
all those operations, we should try to avoid confounding them with yet
another mechanism - so count me in Jeff's camp.
  

We defined capabilities as operations because we could not agree on schema.  If we can agree on attributes such as "password" and "passwordExpirationDate", then a client can do much more in a single request. 

I gave an example in the draft of creating a Person or an Account in a disabled state (with a password that is pre-set and pre-expired).  Today that would take four operations, and they are not atomic. 

Simply put, there is currently no way to create an object in a disabled state.