RE: [wsrp-interfaces] user profile proposal

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

Perhaps one could better signal the change by raising it up a level to a “UserContext2” rather than modifying the “UserContext” type? UserContext2 could restrict and then extend the v1 type to (a) remove the old UserProfile and to (b) add the ability to include multiple profiles. But that may be overkill and may even provoke some stack issues.

 

The other serious disadvantage is that we are less likely to get interop if people just send their user profile data instead of converting to the (P3P derived) 1.0 form. Providing schema information uniformly for all our protocol specializations would be a first step to building up interop again but needs to be done very carefully.

 

Regards,

Andre

 

---

From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 22 August 2005 17:28
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] user profile proposal

 

While conceptually this is a clean method for replaceable user profiles, it does involve a choice that we should be very deliberate in making. The early goals we set out for v2 including striving for backwards compatibility with v1. We have made one break with this goal that I can think of (Property names becoming QNames). One of the arguments for doing that break was the currently minimal implementations of v1 property support. This change would also not be backwards compatible (change in the nesting structure). It can be masked by abstraction layers that most implementations will bring into play, but we should be quite deliberate about introducing such changes.

Rich

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

08/19/05 07:31 AM

To	<wsrp-interfaces@lists.oasis-open.org>
cc
Subject	[wsrp-interfaces] user profile proposal

 

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