In my opinion, the difference is that the “extended
client data item” is seen by the producer, and there is no generic reason
to expect the producer to pass this to the portlet (the client data structures
tend to be monolithic), while the “extended user profile item that
provides the address where a vehicle is garaged” is just a member in a
user profile name-value pairs passed to the portlet as the user profile.
In other words, I believe user profile tends
to be treated by the portlet (content creator), while generic extension
information tend to be treated by the producer (container). Of course, since
anything can be an extension in WSRP, this is a generalization, but I believe
it is the correct way to look at it.
Yossi.
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Wednesday, August 31, 2005
3:49 PM
To:
wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces]
user profile proposal
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
>>
>>
>>
>