RE: [wsrp] custom user profile items broken?

[Rex Brooks <rexb@starbourne.com>]

Would it be possible to work up a set of types, along with with any 
different datatypes other than named strings, based on what implementations 
are being considered? I could take these into the HumanMarkup TC's 
Mediation SC Personalization and Preferences ML effort and suggest that it 
start with some basic needs for user profile types. I think it would be 
wise to consider that there are a wide variety of needs for user profiles 
beyond WSRP-specific requirements, and it would be better to have these 
considered together in one TC rather than in sidebars in various other TCs. 
This need not prevent this TC from standardizing extension types, which 
could later be mapped back to any new standard for user profiles.

Note, one reason we chose Personalization because it is etymologically 
related to the concept of 'person,' which aligns it with HR-XML's usages 
for 'person,' as well as others, such as Rights Languages, that will have 
their namespaces imported into this ML We chose Preferences likewise, and 
we also wanted to avoid explicitly using the word 'profile' which might 
have led to referring to or naming 'profiles of profiles' for various 
subsets and supersets such as the myriad possibilities inherent within the 
class of 'employee.' We are currently fine tuning the subcommittee charter 
and conducting the surveys necessary to begin work on harmonizing and/or 
reconciling existing specifications from domains as diverse as 
e-health-records (EHR), banking and finance, emergency management, human 
resources, marketing research, demographics, law enforcement, etc.

As for the specific arguments in this discussion, I think we need to 
specifically spell out that NamedStrings can be used in extensions, i.e. 
carry it in the UserProfile structure. It will be interesting to see what 
turns up in that field when WSRP 2.0 starts being implemented.

Ciao,
Rex

At 01:49 AM 2/4/2005, Richard Jacob wrote:


>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.

Rex Brooks
President, CEO, Starbourne Communications Design
Executive Director, Humanmarkup.org, Inc.
1361-A Addison
Berkeley, CA 94702
510-849-2309