Re: [provision] Issues on Suspend Capability

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

Martin,
 
Thank you once again for your accurate and insightful review comments.  
We are fortunate to have your involvement in this process.  I'm posting 
this reply to the list primarily to document the discussion of this 
topic during this morning's conference call.

As we discussed in this conference call, you correctly identified an 
inconsistency between the text and the XSD.  During the conference call 
decided to correct the XSD, adding an "effectiveDate" to the 
SuspendRequestType and ResumeRequestType.  I've documented this as XSD 
issue #70 in draft_15_xsd_issues.

With respect to suspending a reference, we explained during the 
conference call that this is not generally possible.  A reference from 
one object to another can be added, modified, or deleted, but the 
reference itself cannot be suspended or resumed.

The exception to this is the case of a "complex" reference.  A complex 
reference has an associated PSO (neither the "from" object nor the "to" 
object but a third object) that contains additional data specific to the 
reference itself.  As Jeff Bohren explained, one use case for this is 
RACF Group Memberships, in which several items of data qualify each 
membership.  A Person not only belongs to a Group but may have 
Administrator or Special privilege.  Several types of memberships 
(including Entrust) include an effective date and expiration date.

In the case of RACF Group Memberships--or another type of reference that 
includes an effective date or an expiration date--a provider could 
choose to support the Suspend Capability for the schema entity "on the 
arrow" (i.e., the schema entity of which an instance is associated with 
a complex reference).  If so, then a requestor could "suspend" such a 
complex reference without having to understand the structure and 
semantics of the schema entity that contains the additional data.  
Otherwise, if the provider did not support the Suspend Capability, a 
requestor could suspend a membership *only* by modifying appropriately 
the additional data in the (third) PSO associated with the reference.

Clear as mud?  Consider it a trial run.  I'll try to explain this next 
within the main spec. ;-)

Raepple, Martin wrote:

> Reviewing the latest draft 0.06 I think there is an inconsistency in 
> the section on the
> Suspend Capability (3.5.8). The description of the 'suspend' and 
> 'resume' operations
> (lines 2725 & 2726) says that both work on an object immediately or on 
> a specified date.
> Since the message schema for SuspendRequestType (and ResumeRequestType)
> has not yet defined an element for a time value, this functionality is 
> currently not
> addressed by the protocol.
>
> Thinking one step further - especially in the context of the 
> discussion on search of
> references - I can't find any information on the effects of these 
> operation regarding the
> references of a suspended / resumed object.  The reader might 
> interpret that only the
> object and none of its references are suspended (which seems to be 
> reasonable). But
> there may be also the need to suspend only a reference (e.g. a 
> person's ownership of
> an account) and not the object itself, again immediately or on a 
> specified date.
>
> To reflect this functionality, the suspend operation schema for 
> example may need to
> be changed like this:
>
>     <complexType name="SuspendRequestType">
>         <complexContent>
>             <extension base="spml:RequestType">
>                 <sequence>
>                     <choice>
>                        <element name="psoId" 
> type="spml:PSOIdentifierType"/>
>                        <element name="reference" 
> type="spmlref:ReferenceType"/>
>                     </choice>
>                 </sequence>
>                 <attribute name="activationTime" type="xsd:dateTime" 
> use="optional"/>
>             </extension>
>         </complexContent>
>     </complexType>
>
> Since I am relatively new to the TC I am not sure whether these issues 
> has been
> already discussed in the group in the past. If not, we may put them on 
> tomorrow's agenda.
>
> Martin
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>  
>