Re: [provision] Issues on Suspend Capability

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

Martin,

I will record as a spec issue that the specification should address 
complex references.  I agree that this will be valuable, and I will try 
to address this in the upcoming Draft 7.

Unfortunately, I must revise my explanation slightly.  Based on my 
reading of the spec and the XSD, the additional data specific to a 
reference are NOT stored as a third PSO, but are instead carried within 
the reference as open content of the <referenceData> element. 

Jeff Bohren explained complex references in terms of a third PSO during 
our most recent conference call.  This is understandable, since the PSTC 
*had* considered this approach to supporting complex references (and 
since this area of the protocol has been one of the most difficult to 
nail down.)  However, the PSTC settled on the <referenceData> approach 
(sometime between the Houston PSTC Face-to-Face (at BMC) and the most 
recent PSTC Face-to-Face in Austin).  As I recall, this coincided with 
our decisions to use open content for various other forms of additional 
data and our decisions to add "wrapper elements" such as 
<capabilityData> to indicate where such open content should reside. 

I responded to your comments on the list *before* reviewing the spec and 
XSD. 
I'll try to be more careful in the future.

Gary

Raepple, Martin wrote:

>thank you for your clear explanation of the complex references
>which catches my point exactly. I also think that we need an additional 
>section on this feature because it is not yet really obvious in the
>spec.
>I'm looking forward to work with you and contribute to the group. 
>
>Kind regards
>Martin
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Mittwoch, 13. April 2005 05:29
>To: Raepple, Martin
>Cc: provision@lists.oasis-open.org
>Subject: Re: [provision] Issues on Suspend Capability
>
>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 
>> 
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>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 
>
>  
>