OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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]