OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] [change request #166] Add UserProfile.profileItem s?


We have no way to pass type models for
RegistrationData.customUserProfileData and all our defined profile data are
strings so this is likely to be the common (even only, as in JSR 168) use
case. We could consider using an array of our Property type for custom
profile data (has both strings and anys). Extension extensions[] are in a
different namespace and I think we should have custom profile data in wsrp's
as well as align this with custom modes, windows states & userCategories.

regards,
Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 21 February 2003 12:25
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [change request #166] Add
UserProfile.profileItems?


I also agree that this is why the extensions element exists in all these 
structures and don't see a need for a second element with undefined 
content.

Rich Thompson




Andre Kramer <andre.kramer@eu.citrix.com>
02/21/2003 04:30 AM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        RE: [wsrp-wsia] [change request #166] Add 
UserProfile.profileItem s?


Extensions are vendor specific (problems in interpreting the ANY you
mention). We should be able to have custom profile data mapped through to 
a
producer/container to a portlet cross vendor. JSR 168 has extensible 
string
User Attributes and we are currently managing to avoiding use of undefined
extensions.

regards,
Andre
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 20 February 2003 22:01
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [change request #166] Add
UserProfile.profileItems?


What's wrong with using the extensions field in the UserProfile 
structure?  Are you concerned because its defined as an ANY?  My 
preference is to find a way to have only 1 extension mechanism in this 
structure.
      -Mike-

Rich Thompson wrote:

>Document: Spec
>Section: 6.1.18 User Profile Types
>Page/Line: 64 / 18
>Requested by: Andre Kramer
>
>Old text: [insert]
>Proposed text: [O] NamedString profileItems
>Description: profileItems: Name / value pairs that are part of a user 
>profile other than the profile names from section 11.
>
>Reasoning: It is not clear where custom profile items are to be sent in 
an 
>interoperable manner. e.g. as negotiated via 
>RegistrationData.customProfileData.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
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