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?



Rex, I don't see any problem with such specialized sets being used with the WSRP protocol. With any such well-known set, type information should be also be well known ...

I think what I am hearing from the discussion is an emerging need to know type information for user profile extensions before runtime. Perhaps this could be well addressed by adding an optional type attribute to the ItemDescription type, but I have not thought through the ramifications on other uses of this type.


Rich



Rex Brooks <rexb@starbourne.com>

02/16/2005 08:24 AM

To
Richard Jacob <richard.jacob@de.ibm.com>, Rich Thompson/Watson/IBM@IBMUS
cc
wsrp@lists.oasis-open.org
Subject
RE: [wsrp] custom user profile items broken?





Correct me if I'm wrong, Richard, Rich, Andre, but both Rich's and
Richard's suggestion leave room for adopting a standardized specification
for "person," "personalization" and "preferences" which are the key terms
we will be focusing on in the HumanMarkup effort in bujilding a "Human
Personalization and Preferences Markup Language," hopefully reconciling and
harmonizing the current crop of specifications out there from HR-XML
Consortium to the growing Electronic Health Records (EHR) work to Emergency
Data Exchange Language (EDXL) work.

The HumanML work will be including a focus on providing the means to
personalize emergency notification systems, which makes the range of
specifications and standards which will need to be included quite wide,
including VXML and WSRP, for which I will trying to bring some specific
individuals into this TC to handle better than I can. I can't put a
reasonable timrline on this work yet, since we have to conduct our outreach
first to, hopefully, gather enough support among the member companies who
can afford to put some paid employee time toward the effort, but the need
is there, and we have made a start with Honeywell and some warning
system-related companies. So, at the least, I want to be able to keep
abreast of how we need to structure the vocabularies we will be creating to
fit WSRP.

Ciao,
Rex

At 04:34 AM 2/16/2005, Richard Jacob wrote:
>Rich Thompson <richt2@us.ibm.com> wrote on 02/07/2005 05:57:21 PM:
>
> >
> > 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?
>
>Well, the key point is that the only clue of custom profile items is the
>name of the item (custom profile items are ItemDescription types).
>There is no way to find out the type (besides reading documentation
>hopefully provided by the producer and consumer and being accurate) of such
>a profile item.
>Therefor there is no means to map these per admin ui and/or
>programmatically.
>You get a clue about the extension's type when it goes over the wire. But
>at this point in time they are pretty useless unless you are able to
>understand them a priori (which is why we often call them "vendor
>extensions").
>
>We did this kind of type definitions for properties, now for events, but we
>don't do it for profile items.
>Therefor custom profile items will remain what they are: propriatary
>extensions which in fact are not very well mappable.
>
> >
> > 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.
>
>But these leads to the case, that products need to code a mapping of
>Consumer profile items to Portlet profile items a priori.
>I was mainly targeting at the custom user profile items provided in the
>portlet description.
>
>Example:
>company X uses com.x.profile.zipCodeLong (Portlet claiming to support this
>one)
>company Y uses com.y.v1.profiles.ourOwnZipCode (Consumer supporting that
>one)
>Wouldn't an admin-managed mapping be both zip codes be desired?
>(Zip code is not an optimal example since it exist in P3P, but...)
>
> >
> > I agree with Andre that we should not introduce a special extensions
> > type just to carry NamedString type custom profile elements.
> >
>I was not proposing a custom extension type, but rather than this
>anticipate that most people will use a flat dotted notation for their
>custom items  (like com.x.profile.itemX) and add
>NamedString[]:customUserProfileItems to the UserProfile type.
>This way we wouldn't need to change anything on the types and descriptions
>(besides this one) and enable an easier usage of cutom items and their
>mappings.
>
> > 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.
> > > 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.
>
>
>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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]