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:]
>Sent: Mittwoch, 13. April 2005 05:29
>To: Raepple, Martin
>Cc:
>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
>
>
>
