RE: [wsrp] custom user profile items broken?

[Richard Jacob <richard.jacob@de.ibm.com>]

Rich Thompson <richt2@us.ibm.com> wrote on 02/07/2005 05:57:21 PM:

>
> I am not understanding the core of the problem/confusion here. Are
> not the following clear?
>
> 1. Every structure in the user profile (including the base level)
> allows for carrying extension items in the standard manner.
>
> 2. Every extension element is required to specify its type using the
> xsi:type attribute. (The general issue of reusing our types in
> extensions is the subject of CR304a and should not need to be
> rehashed just for this context) Is the an emerging need to know the
> type information at design time?

Well, the key point is that the only clue of custom profile items is the
name of the item (custom profile items are ItemDescription types).
There is no way to find out the type (besides reading documentation
hopefully provided by the producer and consumer and being accurate) of such
a profile item.
Therefor there is no means to map these per admin ui and/or
programmatically.
You get a clue about the extension's type when it goes over the wire. But
at this point in time they are pretty useless unless you are able to
understand them a priori (which is why we often call them "vendor
extensions").

We did this kind of type definitions for properties, now for events, but we
don't do it for profile items.
Therefor custom profile items will remain what they are: propriatary
extensions which in fact are not very well mappable.

>
> 3.  Consumers are encouraged to provide a name mapping in the style
> the specification has used for its profile elements. This has the
> custom profile item's name providing the hierarchy by which the item
> can be found at runtime.

But these leads to the case, that products need to code a mapping of
Consumer profile items to Portlet profile items a priori.
I was mainly targeting at the custom user profile items provided in the
portlet description.

Example:
company X uses com.x.profile.zipCodeLong (Portlet claiming to support this
one)
company Y uses com.y.v1.profiles.ourOwnZipCode (Consumer supporting that
one)
Wouldn't an admin-managed mapping be both zip codes be desired?
(Zip code is not an optimal example since it exist in P3P, but...)

>
> I agree with Andre that we should not introduce a special extensions
> type just to carry NamedString type custom profile elements.
>
I was not proposing a custom extension type, but rather than this
anticipate that most people will use a flat dotted notation for their
custom items  (like com.x.profile.itemX) and add
NamedString[]:customUserProfileItems to the UserProfile type.
This way we wouldn't need to change anything on the types and descriptions
(besides this one) and enable an easier usage of cutom items and their
mappings.

> Rich
>

>
> Andre Kramer <andre.kramer@eu.citrix.com>
> 02/04/2005 09:59 AM
>
> To
>
> "'Mike Caffyn'" <mike@netunitysoftware.com>, wsrp@lists.oasis-open.org
>
> cc
>
> Subject
>
> RE: [wsrp] custom user profile items broken?
>
>
>
>
> Should we not encourage use of XML for profile data rather than
> strings in an XML protocol standard?
> But as a more general principle, we should standardize the extension
> mechanism and not the formats used by extenders of the protocol and
> I believe (disregarding the namespace=##other problem) we already
> facilitate passing strings if desired.
> Regards,
> Andre
> -----Original Message-----
> From: Mike Caffyn [mailto:mike@netunitysoftware.com]
> Sent: 04 February 2005 14:34
> To: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp] custom user profile items broken?
> I had the same concerns as Richard, I would agree that there seems to be
a
> standard way to specify which custom profile items are required by the
> producer. But not a standard way of the consumer providing those items
and
> the producer receiving or accessing those items. It would be nice if the
> custom profile items followed the mechanism as the normal profile items.
> This way different producer frameworks all would all give access to the
> custom profile items in standard manner that developers could access
within
> the portlet thus allowing better support for the custom profile items. If

> extensions are used these seem to end up as being a standard for same
> platform and not so good on interop between different portal platforms.
> I like the idea of having namestrings for custom profile items.
> Mike
> ----- Original Message -----
> From: "Richard Jacob" <richard.jacob@de.ibm.com>
> To: "Andre Kramer" <andre.kramer@eu.citrix.com>
> Cc: <wsrp@lists.oasis-open.org>
> Sent: Friday, February 04, 2005 4:49 AM
> Subject: RE: [wsrp] custom user profile items broken?
>

> Andre Kramer <andre.kramer@eu.citrix.com> wrote on 02/04/2005 09:43:19
AM:
> > Option (b) would break compatibility with anyone who took the advice
> > you summarize as (4) - moving named strings from extension elements
> > to a new element.
> well, it wouldn't be moving, it would be just an addition.
> This would be more convenient for developers.
> Another issue here is:
> How can we ever use NamedString in the extension since the Extension type

> only allows namespace=##other ???
> The recommendation we give in 4 doesn't work at all. Every vendor has to
> develop its own NamedString.
> With tha lack of type declaration possibility we loose interoperability.
> >Maybe we should just state that custom profile
> > items are indeed usually carried as named strings in extensions.
> well in general I would agree, but then the extension is kind of limited
to
> contain named strings for this purpose to be interoperable (with the
> remaining "little" namespace=##other issue above)
> In that case I think it would be more convenient to have this directly in

> the UserProfile structure.
> > And
> > this would also lead the extension mechanism to be open to non-
> > string types without requiring (a).
> don't get this. If the extension is used with a custom type, without the
> possibilty to declare it, it's what ít is: an non-interoperable custom
> extension like any other one.
> In that case 6. doesn't make any sense at all.
> > However, guidance on using fully
> > qualified names to avoid potential classes would help as always.
> definitly.
> cheers
> Richard
> > -----Original Message-----
> > From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
> > Sent: 03 February 2005 18:00
> > To: wsrp@lists.oasis-open.org
> > Subject: [wsrp] custom user profile items broken?
> > Hi all,
> > looking more briefly in the handling of custom profile items it seems
to
> me
> > that it is a little bit confusing and inconsistent.
> > 1. ServiceDescription has only ItemDescription for
> customUserProfileItems;
> > i.e. there is no type definition (like for example in model
description)
> > 2. PortletDescription only allows the portlet to declare which item
names
> > (strings) it wants to receive
> > 3. RegistrationData only allows the Consumer to declare which custom
item
> > names it can provide
> > 4. in the description of UserProfile we say that we *expect* the custom

> > items to be extensions and of type named strings, but they *could* be
of
> > other types
> > 5. there is no "customUserProfileItems" of type namedString[] in
> > UserProfile which would fit well with 1,2,3
> > 6. In section 13 "User Information" we say "Consumers supplying
> additional
> > custom profile fields are encourage to publish a similar mapping
between
> > userProfileItems and the custom fields". For me it reads that Consumers

> are
> > encouraged to map profile item names to (custom) profile items
structure
> > they define.
> > Bottom line:
> > It seems that we are pretty inconsistent there and need either fixing
the
> > structures or clarification or even both.
> > I think there are two options:
> > a. enable custom profile items to be of certain types (then we need
> qnames,
> > type definitions, etc.) - they could be model descriptions
> > b. provide a simple name - value pair mechanism where custom profile
> items
> > can be provided. This would for me basically mean to extend the
> UserProfile
> > type to contain an additional field "customUserProfileItems" of type
> > NamedString[].
> > I would prefer b. since I think a. is quite an overkill.
> > If we choose b. we need to fix 4. and 6. and user profile items related

> > sections.
> > I'm happy to receive your opinions :-)
> > Mit freundlichen Gruessen / best regards,
> >         Richard Jacob
> > ______________________________________________________
> > IBM Lab Boeblingen, Germany
> > Dept.8288, WebSphere Portal Server Development
> > WSRP Standardization Technical Lead
> > Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> > Email: mailto:richard.jacob@de.ibm.com
> >
> > To unsubscribe from this mailing list (and be removed from the
> > roster of the OASIS TC), go to http://www.oasis-open.
> > org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
> To unsubscribe from this mailing list (and be removed from the roster of
the
> OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.
>

> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to http://www.oasis-open.
> org/apps/org/workgroup/wsrp/members/leave_workgroup.php.