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
