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:]
Sent: 22 August 2005 17:28
To:
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"
<>
08/19/05 07:31 AM
To
<>
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
