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

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=>
    

    

      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 <>;
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
<>; 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 <>;
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 <>;
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 ; run by ezmlm
    

    

      Precedence: 
      bulk
    

    

      X-No-Archive: 
      yes
    

    

      List-Post: 
      <mailto:>
    

    

      List-Help: 
      <mailto:>
    

    

      List-Unsubscribe:
      
      <mailto:>
    

    

      List-Subscribe:
      
      <mailto:>
    

    

      Delivered-To: 
      mailing list 
    

    

      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: 
      <>
    

    

      To: 
      
    

    

      MIME-Version: 
      1.0
    

    

      X-Mailer: 
      Lotus Notes Release 6.0 September 26, 2002
    

    

      From: 
      Rich Thompson <>
    

    

      Message-ID: 
      "><>
    

    

      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.