[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] user profile proposal
I can't see that the P3P model is to cumbersome. It gives us at least a set
of data which is interchangeble across vendors - a common base of typical
user attributes.
Yes, definitly the P3P model can only be a subset of the real world and
there will always be user attributes which extend that one.
My point is here that what we seem to try now is not extending the P3P
model defined in the protocol but rather *replacing* with custom profile
models.
And I think this is a step backward.
My initial request was to allow extending it in an interoperable reusable
manner without it being merely just a propriatary extension.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Subbu Allamaraju
<subbu@bea.com>
To
08/25/2005 02:41 wsrp-interfaces@lists.oasis-open.or
PM g
cc
Subject
Re: [wsrp-interfaces] user profile
proposal
I'm still open to considering various alternatives, but I would argue
that the current P3P model is too simple and restrictive to be useful in
practice. One might argue that other models of user properties could be
mapped to P3P by way of soma partial mapping and extensions, but it is
turning out to be awkward in practice.
A better model is to use an model content model like Properties, and
make the current P3P model a prespecified type of a Property.
UserContext
string: userContextKey
string[]: userCategories
Property[]: userProfileItems
So, implementors could use the current P3P model as a property, if they
choose to restrict user profiles to P3P. If not, the model is open
enough for arbitrary profiles.
Regards,
Subbu
Richard Jacob wrote:
> I agree with Mike's assessment here.
> The initial intend of the discussion was to define how to *extend* the
P3P
> profiles in an interoprable manner.
> I would not replace the user profiles we have defined fully. This would
be
> less interoperable than today.
> The advantage of having the P3P profiles being defined in our protocol is
> that Consumers/Producer do not need to provide a mapping of various user
> attribute carrying mechanisms.
> The initial missing item I had in mind was
> a) how/where to transfer additional custom user profile items
> b) how to tell the consumer which ones are used so that a mapping of its
> user attributes to the one portlets are interested in can be provided.
>
> Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Team Lead & Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com
>
>
>
> Michael Freedman
> <michael.freedman
> @oracle.com>
To
>
wsrp-interfaces@lists.oasis-open.or
> 08/24/2005 07:42 g
> PM
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
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]