RE: [wsrp-interfaces] user profile proposal

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

what is there is not really enough to work in an interoperable manner.
The profileDescs still require out-of-band negotiations of the types, why
then not negotiate everything out-of-band in that case.
However again I would prefer an interoperable solution enabling mapping
UIs.

Btw. why do we state that customer user profile items MUST be declared in
the customUserProfileItems descr.
Shouldn't it be a MAY?

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


                                                                           
             "Andre Kramer"                                                
             <andre.kramer@eu.                                             
             citrix.com>                                                To 
                                       "Michael Freedman"                  
             08/31/2005 08:46          <michael.freedman@oracle.com>       
             AM                                                         cc 
                                       <wsrp-interfaces@lists.oasis-open.o 
                                       rg>                                 
                                                                   Subject 
                                       RE: [wsrp-interfaces] user profile  
                                       proposal                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




In the use case, the advanced encoding provides additional information over
and above the base “P3P” information. Why re-encode it?

I would also not remove metadata about profiles but would keep pretty much
what we have, which I believe is enough to agree on namespacing for the
exchanged profile elements. [Note Subbu’s comment on our aims here.]

Since the profile information is to be namespaced, one can argue that it
can be freely mixed, but I think a top level separation has advantages and
it’s quite cheap to provide it with the maxOccurs=”unbounded” on the
<profiles> element definition. Then both styles (mixed namespaces or
separated) can be used for user profiles.

Regards,
Andre


From: Michael Freedman [mailto:michael.freedman@oracle.com]
Sent: 30 August 2005 23:29
To: Andre Kramer
Cc: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] user profile proposal

On your answer to multiple profiles:  I don't understand the use case for
this?  What value is there in sending a "common" format and a more
sophisticated format when the consumer and producer both support the
sophisticaed format?

On your answer to extensions vs. things we define in the protocol:  I am
happy to remove the [relatively] useless
customUsiptioerProfileItemDescriptions from serviceDescrn and
customUserProfileData field from registrastionData so that its clear that
this is no different then any other extension that could be supported.
    -Mike-

Andre Kramer wrote:
Just to answer Mike’s questions: Yes, I propose to allow multiple kinds of
profiles. One use case would be allowing the common 1.0 P3P derived values
to be transmitted along with a more sophisticated encoding of additional
user data.

I would agree the XML schema is superficially similar but note that no
<extensions> tag need be used in order to allow the two communicating
parties to exchange profile elements! And that is how it should be for all
explicit extension points we define in the protocol, in my opinion.

Regards,
Andre



From: Michael Freedman [mailto:michael.freedman@oracle.com]
Sent: 24 August 2005 18:43
To: wsrp-interfaces@lists.oasis-open.org
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