[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Issues on Suspend Capability
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]