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] Standard Schema draft 4 - big issues.

I encourage everyone who is interested in this topic to send comments to
the list so we can move this forwards.

I have some comments below.

Jeff B.
-----Original Message-----
From: Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM] 
Sent: Sunday, May 06, 2007 9:08 PM
Subject: [provision] Standard Schema draft 4 - big issues.

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

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

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?

[JSB] I would recommend the sub-object approach.

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.

[JSB] I would recommend that if we include provisioning system specific
classes they be split out into another schema that extends the base
standard schema. There is nothing that limits the "Standard Schema" to
being a single SPML Schema. In other words the "Standard Schema" could
be two actual schema URNs. One that defines the base identity classes
and another that defines the provisioning system specific classes. 

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