[Fwd: [wsrp] [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocalefault]

[Michael Freedman <Michael.Freedman@oracle.com>]

Title:

 Oops, I just realized I hadn't done this TODO from our last conference call
.. here is the message intended to kickoff discussion:

I submitted the change request [appended] because its not clear how we intend
consumers/producers to behave with respect to the locale information published
by the producer about a given portlet.  I.e. If a producer publishes a locale
list in MarkupType [page 20, line 24] is this an exclusive list?  I.e. the
consumer can safely choose to ignore this portlet if it needs a different
locale [and doesn't want to support mixed locales]?    Basically, are we
saying that if the producer publishes this information then the consumer
should restrict the requested list by this list? And if it doesn't [without
also indicating it handles anything via passing *] then it should expect
this exception?  If so, then it seems strange to provide this exception [so
the consumer can gracefully recover] vs it merely doing the check before
making the call.  Or is this exception added for the situation that the producer
didn't publish a list of locales and the consumer asks for one that isn't
supported?  But again the document seems to say that by leaving this list
out the producer will try its best -- so why again isn't it reasonable that
the producer always return content in this situation [which contains the
locale information] and the consumer merely inspect it and decide what to
do?

To make this simplier what can the consumer count on in terms of what/how
the producer works when:
       a) the producer passes a list of locales in the PD
       b) the producer leaves out the locales in the PD

And for each of the above, what is the circumstance under which the producer
would throw the UnsupportedLocale exception?
      -Mike-

-------- Original Message --------

Return-Path:	<wsrp-return-27-michael.freedman=oracle.com@lists.oasis-open.org>
Received:	from rgmgw6.us.oracle.com (localhost [127.0.0.1]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2KD4dm26745 for <michael.freedman@oracle.com>; Thu, 20 Mar 2003 06:04:39 -0700 (MST)
Received:	from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by rgmgw6.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h2KD4cb26727 for <michael.freedman@oracle.com>; Thu, 20 Mar 2003 06:04:38 -0700 (MST)
Received:	from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2KD4bh18520 for <michael.freedman@oracle.com>; Thu, 20 Mar 2003 05:04:37 -0800 (PST)
Received:	from mail.oasis-open.org ([209.202.168.102]) by inet-mail1.oracle.com (Switch-2.2.5/Switch-2.2.5) with SMTP id h2KD4bW18509 for <michael.freedman@oracle.com>; Thu, 20 Mar 2003 05:04:37 -0800 (PST)
Received:	(qmail 20847 invoked by uid 508); 20 Mar 2003 12:56:43 -0000
Mailing-List:	contact wsrp-help@lists.oasis-open.org; run by ezmlm
Precedence:	bulk
X-No-Archive:	yes
List-Post:	<mailto:wsrp@lists.oasis-open.org>
List-Help:	<mailto:wsrp-help@lists.oasis-open.org>
List-Unsubscribe:	<mailto:wsrp-unsubscribe@lists.oasis-open.org>
List-Subscribe:	<mailto:wsrp-subscribe@lists.oasis-open.org>
Delivered-To:	mailing list wsrp@lists.oasis-open.org
Received:	(qmail 20840 invoked by uid 60881); 20 Mar 2003 12:56:43 -0000
X-Spam-Status:	No, hits=0.0 required=8.0
In-Reply-To:	<3E791717.8000200@oracle.com>
To:	wsrp@lists.oasis-open.org
MIME-Version:	1.0
X-Mailer:	Lotus Notes Release 6.0 September 26, 2002
From:	Rich Thompson <richt2@us.ibm.com>
Message-ID:	OFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm.com"><OFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm.com>
Date:	Thu, 20 Mar 2003 08:04:30 -0500
X-MIMETrack:	Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|March 14, 2003) at 03/20/2003 08:04:31, Serialize complete at 03/20/2003 08:04:31
Content-Type:	multipart/alternative; boundary="=_alternative 0047D30F85256CEF_="
Subject:	[wsrp] [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocale fault

Document: Spec
 Section: 6.2.1 +
 Page/Line: 43/21
 Requested by: Michael Freedman
 Old text: Interface.UnsupportedLocale
 New text: remove this exception
 Reasoning: Do we really want the producer/portlet to throw this explicit 
 exception if it can't match the requested locale?  Wouldn't it be better
 if portlets thought of the consumers list as preferred locales and 
 merely returned the markup with whatever locale it decided to use?  The 
 consumer could then decide what it wanted to do.  This fits a little 
 better in the world where the portlet is implemented in Java as 
 parts/much of the content may come from resource bundles which always 
 resolve to a default whether the requested locale exists or not.  In the
 end, if a portlet wants to merely abort the render and return an 
 exception it can always use Interface.OperationFailed.  I.e. as the 
 consumer has the portlet meta data that indicates what locales its 
 supports it seems that those consumers that want to ban inappropriate 
 locales can choose to do so be not calling the render method based on 
 this information.  Right now, a consumer that wants content no matter 
 what is forced to explicitly pass * as the last entry in its list.