[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Issues on Suspend Capability
Thank you. Those new sections are already incorporated in (the still un-released) Draft 7. Raepple, Martin wrote: >The new discussion of complex references and the description of the >workaround >seem logical to me. Using the analogy of a normalized database to >explain the >need for relationship objects is an excellent way to help the reader >understanding >the issue. We should add the new sections to the next draft version. > >Martin > >PS: Due to a conflict I will not be able to attend the SPML call next >week (March 26th) >-----Original Message----- >From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] >Sent: Montag, 18. April 2005 00:48 >To: PSTC >Subject: Re: [provision] Issues on Suspend Capability > >Attached is a draft of the revised Reference Capability section. The >main change is the new discussion of Complex References. I use RACF >Group Memberships as an example of complex reference type. I also >discuss limitations of modeling complex relationships as references, and > >discuss how a provider could use an object to represent each instance of > >a complex relationship. > >I left the titles of the sections preceding the reference capability >section (just to keep the outline numbers the same), but I removed all >of the content (to keep the attachment small and to keep the review >focussed on this section). > >Aside from this section, most of the changes so far in Draft 7 have been > >small. I probably will not release Draft 7 until I get a new XSD >version from Jeff Bohren or a new Security and Privacy section from Hal >Lockhart. (Even a new Security and Privacy section won't affect other >sections and could be reviewed independently--like this one. I'll >probably wait for the new XSD version.) > >Please let me know what you think about this Reference Capability >section, so that I can address those review comments into Draft 7. > >Gary P Cole wrote: > > > >>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 > > >>> >>> >>> >>> >>--------------------------------------------------------------------- >>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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]