[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] user profile proposal
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:richard.jacob@de.ibm.com > > > > Subbu Allamaraju > <subbu@bea.com> > To > 08/31/2005 02:07 wsrp-interfaces@lists.oasis-open.or > 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:michael.freedman@oracle.com] > >> *Sent:* 24 August 2005 18:43 > >> *To:* wsrp-interfaces@lists.oasis-open.org > >> *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]