[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] custom user profile items broken?
On a related note, to our experience, most customers prefer custom profiles, and rarely use P3P profile data. Given this, it would be convenient to treat custom profile data as first-class citizens, and use something similar to properties for metadata/runtime. This will avoid the need for using extensions. Regards, Subbu Rich Thompson wrote: > > 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? > > 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. > > I agree with Andre that we should not introduce a special extensions > type just to carry NamedString type custom profile elements. > > 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_ > <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_. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]