OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Title: Re: [provision] Operational attributes (was "Re: [provision] Standard Schema draft 4 - big issues.")
After today’s call I thought harder about this... and there’s Gary’s comment – thanks for the clarification.  

In short, I was misguided in thinking of operational attributes as side-effect inducing attributes, rather, they are effectively state. (dare I say representations of state?)

Therefore, if we have a consensus schema and we can use fewer operations to accomplish the same things, like suspending an account, then that’s a win. With a standard schema that includes operational attributes and just the SPML Core, one could do the vast majority of the services in the complete specification.  Simple is a good thing.

So allow me to recant – I favor fewer operations over more; which implies operational attributes.  

(and makes ‘initial attributes’ a moot point?)


On 5/22/07 9:53 AM, "Bohren, Jeff" <Jeff_Bohren@BMC.com> wrote:

I just had another idea. Suppose we created optional attributes that are only used for create operations and give them a special name. For instance we could have attributes like:
These be semantically defined to only be meaningful on create operations. This would allow us a mechanism to create persons and accounts in a disabled state, while still requiring the capability 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 indicate that they could optionally be used on create, but would be ignored otherwise.
How does that sound?

Jeff B.

From: Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM]
Sent: Tuesday, May 22, 2007 11:29 AM
To: Kent Spaulding
Subject: [provision] Operational attributes (was "Re: [provision] Standard Schema draft 4 - big issues.")

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> <mailto: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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]