RE: [wsrp-interfaces] user profile proposal

["Andre Kramer" <andre.kramer@eu.citrix.com>]

Title: user profile proposal

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