My choice would be to fix this, given that user profiles are an
important part of personalization in most web-based apps today.
Subbu
Richard Jacob wrote:
> Right, this was the initial intent.
> It seems that we now do not agree on this?
> Therfore we should clearly answer this question first:
>
> Do we want to support interoprable custom profile exchange (and thus
> mapping of different profile sets)?
>
> If the answer is yes, we should continue and try to fix the leaks we
> identified.
> If the answer is no, I tend to agree that the current
> customUserProfileItemDesc is close to useless.
>
> 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/31/2005 02:07
> AM g
> cc
>
> Subject
> Re: [wsrp-interfaces] user profile
> proposal
>
>
>
>
>
>
>
>
>
>
> > On your answer to extensions vs. things we define in the protocol: I am
> > happy to remove the [relatively] useless
> > customUsiptioerProfileItemDescriptions from serviceDescrn and
> > customUserProfileData field from registrastionData so that its clear
> > that this is no different then any other extension that could be
> > supported.
>
> But isn't the whole debate about making custom profile items more useful
> than they are currently.
>
> Subbu
>
>
> > -Mike-
> >
> > Andre Kramer wrote:
> >
> >> Just to answer Mike’s questions: Yes, I propose to allow multiple
> >> kinds of profiles. One use case would be allowing the common 1.0 P3P
> >> derived values to be transmitted along with a more sophisticated
> >> encoding of additional user data.
> >>
> >>
> >>
> >> I would agree the XML schema is superficially similar but note that no
> >> <extensions> tag need be used in order to allow the two communicating
> >> parties to exchange profile elements! And that is how it should be for
> >> all explicit extension points we define in the protocol, in my opinion.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Andre
> >>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >> *From:* Michael Freedman [mailto:]
> >> *Sent:* 24 August 2005 18:43
> >> *To:*
> >> *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
> >>
> >>
> >>
> >
>
