Re: [provision] Standard Schema draft 4 - big issues.

[Kent Spaulding <kent.spaulding@ttg.cc>]

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:

> I appreciate the review comments I've received from the PSTC.  (I have not yet
> responded to James Hu, but his comments are also excellent.)
> 
> Unfortunately, I doubt that I will be able to call in to the PSTC con call on
> Tuesday.   I will be attending Java One conference.
> 
> Could we discuss on the alias some of the issues?  I think I
> can collect the issues and bring to the top some of the biggest ones.
> If we decide a few of the major issues, then many of the others may follow.
> 
> For example, I feel that some of the biggest questions were:
> 
> 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.

> 
> 2) Should the Schema represent a subordinate entity (e.g., an address) as a
> complex attribute, or can we represent each as a sub-object?
> 
> NOTE: Martin Raepple and I favor the sub-object approach (which would
> represent Address as an object-class).  Does anyone strongly disagree?

I strongly agree.
 
> 
> 3) Should the Schema include object-classes that make sense only to a
> provisioning system?
> 
> NOTE: Jeff Bohren says no, but I point out that SPML is a provisioning markup
> language.  Since object-classes are optional, a provider that does not wish to
> support them can simply omit them from its schema.
> 

I agree - allow object-classes that are provisioning specific.

--Kent