Title: 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
