This points back to the scenario I find
more natural. Given that all of the fields within UserProfile are optional,
the extensions element there would be the place to hang such info as it
inherently identifies it as UserProfile info and not just UserContext info.
For example, an intranet application pulling info from an LDAP server into
an existing schema might find it useful to send:
<userProfile>
<extensions>
<employee>
<firstName>Richard</firstName>
...
</employee>
</extensions>
</userProfile>
Rich
Michael Freedman <>
08/24/05 01:42 PM
To
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
