Interoperability should also consider 3rd
party tools (e.g. a XML gateway / application level firewall) so encouraging
(via SHOULD) spec defined names on the wire is the right thing to do (both
sides).
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 05 May 2005 19:36
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] [CR315] -
Producers SHOULD or MAY do userProfile namemapping
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