[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]