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:
>
>
>
> Subbu Allamaraju
> <>
> To
> 08/25/2005 02:41
> 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:
> >
> >
> >
>
> > Michael Freedman
>
> > <michael.freedman
>
> > @oracle.com>
> To
> >
>
> > 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
> >
> >
> >
> >
>
