[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#118] RegistrationData.userProfileExtensions[]needsa des crip tion sub-element
See inline comment. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Thursday, October 24, 2002 5:11 AM To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] [I#118] RegistrationData.userProfileExtensions[] needsa des crip tion sub-element I think there is some confusion on usage here. RegistrationData.userProfileExtensions (a String[]) is a field the Consumer sends to the Producer declaring what extensions are available from the Consumer. The security (if I remember correctly) subgroup expected these to be named sets both parties would understand (spec uses "SAP-R3-UserProfile" as an example). mm1: I believe this is true. EntityDescription.userProfileItems (a String[]) is the field where an entity declares the set of profile items it seeks access to. The spec currently anticipates these come directly from either the base set of profile fields or those the Consumer declared as available. If we want to expand this semantics, I would agree that String[] is the wrong type and that we will need to define an additional structure. Do we want to expand the semantics to effectively the entity declaring in general what it is able to use? Gil Tayar <Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org lage.com> cc: Subject: [wsrp-wsia] [I#118] 10/24/2002 03:47 RegistrationData.userProfileExtensions[] needs a des crip AM tion sub-element Status: Active Topic: Registration Class: Minor Techical Title: RegistrationData.userProfileExtensions[] needs a description sub-element Document Section: Draft-WSIA-WSRP_Core_Interface-v0.8, Section 6.1.1 Description: The userProfileExtensions sub-element of RegistrationData is just a String array, permitting the Producer to inform the Consumer of the names of user profile extensions it wishes to receive. By itself, the name is pretty useless to the Consumer, who has the task of trying to map the named extension to something comparable in its own User management system. Typically this would need to be a manual task, and I think that a human administrator would like not just a name, but also a text description of what the Producer expects as a value for this field. This is also an interoperability issue with JSR 168, which allows the portlet to specify the name and description of the custom user attributes it wants the portal to provide. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC