Re: [wsrp] custom user profile items broken?

["Mike Caffyn" <mike@netunitysoftware.com>]

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.