[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] user profile proposal
Richard Jacob wrote: > 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. Not replacing, but treating it as a subset of the real-world model in the proposal I made below. Currently we are trying to map the real-world model into the P3P model. Regards, Subbu > 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]