I think my concern with the original spec was the
fact that the producer can use a well defined way of requesting a custom user
profile item but there wasn't a well defined way of the consumer providing it or
the producer receiving it. It was done via the extensions, thus maybe different
consumers may provide the what is seen as the same Custom User Profile items in
different manners therefore not being so interoperable. Lets do something simple
like the User Profile Items themselves.
Maybe I'm just confused on this subject it
seems to be going around and around :-)
Mike
----- Original Message -----
From:
Rich Thompson
To:
Sent: Wednesday, August 31, 2005 9:26
AM
Subject: Re: [wsrp-interfaces] user
profile proposal
I agree that the spec defines
additional semantics for both events and properties even those these also use
an open content model.
I don't see
anything in any of the user profile proposals that defines additional
semantics for extended user profile items. Rather all the proposals appear to
simply carry these in different manners and I see no value in doing that. I
could be missing additional semantics the spec would define and, if that is
the case, would seriously like to be enlightened.
Rich
Subbu Allamaraju
<>
08/31/05 09:19 AM
To
cc
Subject
Re: [wsrp-interfaces] user
profile proposal
If I understand your argument correctly, your key reason for treating
these the same is that both use an open content model at the XML level.
The moment we treat a spec defined user profile item and an extension
the same way, we can apply the same argument at several other places,
leading a to very weak schema and spec. For example, why not carry
portlet properties or events as extensions? Or why not carry export data
as an extension?
We don't want that since an event is an event, a
property is a property,
and an extensions is ... what? We don't know what
it is, expect that it
has an open content model. They are for spec-users
to specify
(semantically).
Not attempting to be enlightening
...
Subbu
Rich Thompson wrote:
>
> 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
<>*
>
> 08/30/05 08:07 PM
>
>
>
To
>
> 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:]
> >> *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
> >>
> >>
>
>>
> >
>
>
