This would formalize the convention of
making a QNAME point to an XML schema doc. Which is something one can do today for
ItemDescriptions but I agree should be directly supported.
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 16 February 2005 15:18
To: wsrp@lists.oasis-open.org
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