> 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
>>
>>
>>
>
