I agree that we tried (and failed) to
provide such a mapping for extended user profile items in v1.
What I fail to see is why this would
be different from mappings for items that extend other types. For example;
if the Producer uses a different type to represent extended information
about the user device, why wouldn't the mapping issues be identical?
Rich
Richard Jacob <>
08/31/05 10:17 AM
To
Rich Thompson/Watson/IBM@IBMUS
cc
Subject
Re: [wsrp-interfaces] user profile proposal
I see a difference here.
The key point for me is that the protocol should enable the mapping of
various profile item sets which go beyond what we have defined with the
P3P
attributes already.
So here is an example of two simple sets having the same semantics but
using different syntax/schema (in simple string notation):
companyA.car.address.street
companyA.car.address.zipcode
...
companyB.vehicleinfo.car1.address.streetname
companyB.vehicleinfo.car1.address.codezip
...
Enabling the portlet to a) express the semantics AND b) express the type
information allows the Consumer to generate a mapping - for example when
integrating the remote portlet via an UI.
Anything less then this means in fact out-of-band.
And I think it is quite arguable that some portions of the protocol might
be worth to enable a mapping with the help of the protocol but others may
not.
The user profile items are the best candidate for me.
And I think we tried to express that in V1 with the customUserProfDesc,
but
in my opinion failed.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:
Rich Thompson
<
m>
To
08/31/2005 03:26
g
PM
cc
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
is-open.org
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
> >>
> >>
> >>
> >
>
>
