|Rex Brooks||Feb 4, 2005 6:16 am|
|Subject:||RE: [wsrp] custom user profile items broken?|
|From:||Rex Brooks (re...@starbourne.com)|
|Date:||Feb 4, 2005 6:16:04 am|
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.
At 01:49 AM 2/4/2005, Richard Jacob wrote:
Andre Kramer <andr...@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.
-----Original Message----- From: Richard Jacob [mailto:rich...@de.ibm.com] Sent: 03 February 2005 18:00 To: ws...@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:rich...@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