[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Spec issue #58: Provider may need to know requester's profile.
Jeff Bohren suggested adding a "profile" attribute to the ListTargetsRequestType and also adding a "profile" attribute to TargetType. I think those are good ideas, and I think the changes will affect only the listTargets operation. Here's how I think it should work. The "profile" attribute of ListTargetsRequestType should be optional. If "profile" is specified, its value is an XML namespace (like a capability name). - If a listTargetsRequest specifies a profile and the provider does NOT support the profile then the provider must return ErrorCode#unsupportedProfile. - If a listTargetsRequest specifies a profile and the provider DOES support the profile then the listTargetsResponse should contain only targets that fit the profile. - If a listTargetsRequest does NOT specify a profile, then the provider should behave as it does today and the listTargetsResponse should contain every target. Gary P Cole wrote: > I think we forgot about this one. I never recorded it as a spec issue > or an XSD issue. Do we still want to make these changes? > > Bohren, Jeffrey wrote: > >> I agree that it would be very useful for a single SPML service to >> support >> multiple profiles. In addition to allowing the client to specify the >> profile >> on the listTargets request, the supported profile should be returned >> on the >> targets returned in the response. >> Jeff Bohren >> BMC >> >> -----Original Message----- From: Gary P Cole >> [mailto:Gary.P.Cole@Sun.COM] Sent: Fri 5/13/2005 12:12 PM To: PSTC >> Cc: Subject: [provision] Provider may need to know requester's profile. >> >> >> >> An SPML profile represents a set of assumptions about how requestor >> and provider will use SPML. The requestor should probably pass a >> profile identifier in with a listTargetsRequest. The provider may >> want to expose a different set of targets for each profile. >> For example, suppose that a provider can expose the same target >> (system or application) with either native XML schema *or* with the >> DSMLv2 schema model. If the provider knows what the requestor wants >> or expects, the provider can return a target that suits the >> requestor's profile. >> Otherwise, I guess the provider could return both targets (even if >> both represent the same underlying system or application) and let the >> requestor decide, based on each target's schema, which target the >> requestor prefers. >> >> --------------------------------------------------------------------- >> 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 >> <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]