Title: 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:]
Sent: 24 August 2005
18:43
To:
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
