Re: [wsrp-interfaces] user profile proposal

[Richard Jacob <richard.jacob@de.ibm.com>]

I agree with Mike's assessment here.
The initial intend of the discussion was to define how to *extend* the P3P
profiles in an interoprable manner.
I would not replace the user profiles we have defined fully. This would be
less interoperable than today.
The advantage of having the P3P profiles being defined in our protocol is
that Consumers/Producer do not need to provide a mapping of various user
attribute carrying mechanisms.
The initial missing item I had in mind was
a) how/where to transfer additional custom user profile items
b) how to tell the consumer which ones are used so that a mapping of its
user attributes to the one portlets are interested in can be provided.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Michael Freedman                                              
             <michael.freedman                                             
             @oracle.com>                                               To 
                                       wsrp-interfaces@lists.oasis-open.or 
             08/24/2005 07:42          g                                   
             PM                                                         cc 
                                                                           
                                                                   Subject 
                                       Re: [wsrp-interfaces] user profile  
                                       proposal                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Why did you define this so the producer can receive multiple profiles?
What is the use case for this?  Where do we expect consumers to
manage/construct more then one?

Also, I find it interesting that in the end you have turned user profiles
into an extension.  i.e. they have the same form.  To me this is a step
backwards -- and instead I would prefer to continue to carry the P3P style
user profile formally in the UserContext as we did in 1.0 to reflect the
fact that this is the preferred/protocol profile and then tell
consumers/producers that decide to use a different profile to merely carry
that profile in the extensions field. This is especially true given your
strong preference not to attempt to provide more meta data in the protocol
related to user profiles
    -Mike-


Andre Kramer wrote:


      The following should allow alternative types of profile data to flow,
      making our old P3P based information one example of such profile
      descriptions:


      In 1.0 we had:


      <complexType name="UserContext">


         <sequence>


              <element name="userContextKey" type="xsd:string" />


              <element name="userCategories" type="xsd:string" minOccurs="0
      " maxOccurs="unbounded" />


              <element name="profile" type="types:UserProfile" minOccurs="0
      " />


              <element name="extensions" type="types:Extension" minOccurs="
      0" maxOccurs="unbounded" />


         </sequence>


      </complexType>


      <element name="UserContext" type="types:UserContext" />


      Proposal: Replace "profile" element in above with a "profiles"
      element (note different type and that mulitple occurances are now
      allowed):


      <element name="profiles" type="types:Profile" minOccurs="0"
      maxOccurs="unbounded" />


      Where the new Profile type is defined as follows:


      <complexType name="Profile">


         <sequence>


              <any />


         </sequence>


      </complexType>


      We would also define a global  "userProfile" element, as well as keep
      the (P3P) UserProfile type in our schema (could move UserProfile to
      separate useful types xsd):


      <element name="userProfile" type="types:UserProfile"/>


      This allows 0, 1 or many profiles to be communicated in the user
      context in <profiles> elements. The understanding is that all such
      profiles relate to the user. A specific usage is to communicate the
      1.0 UserProfile data. This would now be carried in an element named "
      profiles" :


      <userContext>


         ...


         <profiles>


              <userProfile> … 1.0 P3P stuff  ...</userProfile> <!-- note
      that userProfile element is NOT required to be here but some XML is.
      -->


         </profiles>


         …


         <extensions> … </extensions> ...


      </userContext>


      Possible types of profiles can be listed using ServiceDescription.
      customUserProfileItemDescriptions and RegistrationData
      .customUserProfileData. On reflection, I strongly prefer not to
      attempt to provide more meta data in the protocol related to user
      profiles. If a XML processor recognizes the namespaced elements it
      will already have the schema (if defined).


      Regards,


      Andre