wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] [CR315] - Producers SHOULD or MAY do userProfile name mapping
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 5 May 2005 14:35:42 -0400
I understand the sentiment, but doubt
it really works. Consider the case where the Consumer and Producer each
have their own user profile item names which are distinct both from each
other and the spec defined names, but with roughly 90% overlap on a semantic
level (I suspect this is the normal cross-vendor case!). I think both need
to have a requirement to maps their unique names to spec defined names
where semantics match. The remaining names could be mapped by either side,
but preferably this is done by whomever has the knowledge required to declare
matching semantics.
Rich
Subbu Allamaraju <subbu@bea.com>
05/05/05 02:17 PM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsrp] [CR315] - Producers
SHOULD or MAY do userProfile name mapping |
|
Rich Thompson wrote:
>
> I don't see this as an interop issue as it relates to making use of
> additional data and therefore relates to interop in the same manner
as
> extension elements.
>
> I think we had quite a debate about this in the v1 timeframe and came
to
> the consensus that any such mapping was going to require that someone
> either know or be able to guess that two different user profile items
> had the same semantics. As such, we decided to encourage both sides
to
> support name mapping so that the knowledge could be applied regardless
> of on which partner's end the knowledge existed.
>
> The potential interop issue would be if neither side made an effort
to
> map their internal user profile items to the spec defined set. The
> potential change I could see adding in this area would be to add a
> requirement that such mappings be done.
That's right. This is what I was referring to when I commented about
possible interop issues. One of the parties must do the mapping to get
this to work, and I feel that we should have a stronger requirement on
the consumer, and a weaker requirement on the producer for mapping.
Subbu
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 05/04/05 02:28 PM
>
>
> To
> wsrp@lists.oasis-open.org
> cc
>
> Subject
> Re:
[wsrp] [CR315] - Producers SHOULD or MAY do userProfile name mapping
>
>
>
>
>
>
>
>
> Good point. However, there is room for interpretation of "valid
> reasons". We gain interop by treating SHOULD as a "MUST
except under
> extraordinary circumstances", and encourage implementations to
honor
> SHOULD under normal circumstances.
>
> For this change request, if a Producer treats SHOULD as a MAY and
does
> not do mapping, it would affect interop. Moreover, having two similar
> conformance statements for both the Consumer and the Producer also
> affects interop. Since both conformance statements use SHOULD, it
is
> unclear what the guidance is, and how interop can be achieved?
>
> Regards,
>
> Subbu
>
>
> Rich Thompson wrote:
> >
> > Since this will be a debate over the application of conformance
> > language, the following are the copied definitions from
RFC2119:
> >
> > *SHOULD*: This word, or the adjective "RECOMMENDED",
mean that there may
> > exist valid reasons in particular circumstances to ignore
a particular
> > item, but the full implications must be understood and
carefully weighed
> > before choosing a different course.
> >
> > *MAY*: This word, or the adjective "OPTIONAL",
mean that an item is
> > truly optional. One vendor may choose to include
the item because a
> > particular marketplace requires it or because the vendor
feels that it
> > enhances the product while another vendor may omit the
same item. An
> > implementation which does not include a particular option
MUST be
> > prepared to interoperate with another implementation which
does include
> > the option, though perhaps with reduced functionality.
In the same vein
> > an implementation which does include a particular option
MUST be
> > prepared to interoperate with another implementation which
does not
> > include the option (except, of course, for the feature
the option
> > provides.)
> >
> >
> > Saying the Producer SHOULD map user profile names allows
for Producers
> > to choose not to support name mapping (a valid reason for
some
> > implementations would be the impact on the PortletDescription
of POPs),
> > but does require that people understand the implications
of that choice
> > (less likely to receive the data). Reducing this
to "MAY" does not
> > require the Consumer to do the name mapping, though it
does make it
> > easier for Producer developers to blow by the statement.
> >
> > Note: There is a corresponding SHOULD relative to Consumers
mapping
> > custom user profile names.
> >
> > Rich
> >
> >
> > *Rich Thompson/Watson/IBM@IBMUS*
> >
> > 05/04/05 01:32 PM
> >
> >
> > To
> >
wsrp@lists.oasis-open.org
> > cc
> >
> > Subject
> >
[wsrp] [CR315] - Producers SHOULD or MAY do
> userProfile name mapping
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Document: Specification 2.0 Draft
> > Requested by: Subbu Allamaraju
> > Section: 5.1.2 PortletDescription Type
> > Page: 25
> > Line: 17
> > Old Text:
> > Any use of additional userProfile items specified as available
when the
> > Consumer registered SHOULD use the names the Consumer supplied.
> >
> > New Text:
> > Any use of additional userProfile items specified as available
when the
> > Consumer registered *MAY *use the names the Consumer supplied.
> >
> > Reasoning:
> > The current text places the burden on the producer to do
the mapping.
> > Since this requires the producer to change the portlet
description after
> > registration, producers will be required to maintain different
portlet
> > description for each portlet (even for POPs). The changed
text
> > would place less burden on producers. Producers can still
do the
> > mapping, but it should be completely optional (MAY).
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]