I just had
another idea. Suppose we created
optional attributes that are only used for create operations and give
special name. For instance we could have attributes like:
semantically defined to only be
meaningful on create operations. This would allow us a mechanism to
persons and accounts in a disabled state, while still requiring the
specific operations to suspend/restore and set passwords.
I am not
suggesting any change to the
specification. Just descriptions in each of the attributes that
they could optionally be used on create, but would be ignored
Sent: Tuesday, May 22,
To: Kent Spaulding
attributes (was "Re: [provision] Standard Schema draft 4 - big
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
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
state (with a password that is pre-set and pre-expired). Today that
take four operations, and they are not atomic.
Simply put, there is currently no way to create an object in a disabled