Re: [wsrp-interfaces] user profile proposal

[Rich Thompson <richt2@us.ibm.com>]

As this discussion has been proceeding,
I am becoming more convinced that we are trying to draw an artificial distinction
between custom user profile items and extensions. In v1, we put a minor
hook for describing extensions related to the user profile because we expected
these to be common, but the further we move from that original model, the
more this looks artificial to me.

Can someone clearly articulate a concrete
difference between a Consumer supplying an extended user profile item that
provides the address where a vehicle is garaged and a Consumer supplying
an extended client data item that provides information about the user's
device???

What I see:
 - In both cases, the protocol
provides a defined extensibility point (using an open content model) for
carrying the extended information (regardless of which proposal one is
preferring)
 - In both cases, the only semantics
the protocol defines is that the extended information is related to the
type which carries it (section 5.1.1 and equivalent in the various user
profile proposals)
 - In both cases, the Consumer
needs to supply identity, syntactic and semantic information to the Producer
in order for the information to be useful.
 - In both cases, these points
combine to produce the warning the spec includes in 5.1.1 that such items
are less interoperable than spec-defined items.

What I don't see are differences from
a protocol perspective! 
I look forward to being enlightened
...

Rich

Subbu Allamaraju <subbu@bea.com>

08/30/05 08:07 PM

To	wsrp-interfaces@lists.oasis-open.org
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
>>
>>  
>>
>