[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]