OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Mike I agree with you.
I think we are pretty unspecific.
When re-reading the concerned sections I think that we are not saying that
the consumer should restrict the requested list by the locales list
published in the MarkupType. However I would understand this as a hint for
the consumer to see what locales are supported (and thus request only
these) - and remember: these may change during runtime.
Another indicator for me that the producer generates markup on a
best-effort basis is that in MarkupParams the consumer passes a locales
list it would *prefer* the markup to be in. However the producer still may
generate one of these. If it would be an "exclusive list" as you are asking
then it should be safe to pass only one locale in MarkupParams?
I don't think we allow to pass "*" in locales to indicate that the consumer
accept any locale.
However I think this is a lack in our spec it should be possible to pass
null for the locales[] to indicate that any language is accepted? Currently
the field is required.

I could imagine two samantics concerning this discussion:
1. keep the exception, no fall back
Then in MarkupType the portlet MUST specifiy the supported locales, null
should not be allowed as this mixes two semantics: fallback and exception.
In MarkupParams the consumer SHOULD pass only a subset the locales
supported by the portlet or null if it accepts any locale (change of
locales[] from required to optional) - here it must be SHOULD and not MUST
because the descriptions may change, in case of MUST the consumer would
have to check always the description prior to the getMarkup call.
The portlet must throw an unsupportedLocale exception if it is not able to
provide a requested locale - btw. it should be unsupportedLocales as the
consumer may request multiple locales, the message might list these
It must not throw this exception if null was passed but instead gently
deliver markup in the locale choosen by the portlet.

2. best-effort behaviour, drop exception
The PortletDescription delivers a hint to the consumer which locales are
supported, it may to choose not to provide any indication.
In MarkupParams the consumer passes a set of locales in priority order it
likes the markup to be. This set SHOULD be a subset of the locales found in
The consumer MAY pass null to indicate it accepts any locale.
The portlet SHOULD generate markup in the locale requested (by priority).
In case of null the portlet chooses to return markup in any locale it

I could go either way.
I think we are handling markupTypes more in the 2. fashion and say the
portlet SHOULD generate markup in one of the requested markupTypes (MIME
So 2. seems to be more consistent.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com

|         |           Michael Freedman  |
|         |           <Michael.Freedman@|
|         |           oracle.com>       |
|         |                             |
|         |           03/26/2003 02:24  |
|         |           AM                |
  |                                                                                                                                                  |
  |       To:       WSRP <wsrp@lists.oasis-open.org>                                                                                                 |
  |       cc:                                                                                                                                        |
  |       Subject:  [Fwd: [wsrp] [wsrp-wsia] [change request #240] Remove Interface.UnsupportedLocale fault]                                         |

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?

-------- Original Message --------
 Return <wsrp-return-27-michael.freedman=oracle.com@lists.oasis-open.org>  
 Receiv from rgmgw6.us.oracle.com (localhost []) by               
    ed: 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)                                               
 Receiv from inet-mail1.oracle.com (inet-mail1.oracle.com [])  
    ed: 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)                                               
 Receiv from inet-mail1.oracle.com (localhost []) by              
    ed: 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)                                               
 Receiv from mail.oasis-open.org ([]) by                    
    ed: 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)                                               
 Receiv (qmail 20847 invoked by uid 508); 20 Mar 2003 12:56:43 -0000       
 Mailin contact wsrp-help@lists.oasis-open.org; run by ezmlm               
 Preced bulk                                                               
 X-No-A yes                                                                
 List-P <mailto:wsrp@lists.oasis-open.org>                                 
 List-H <mailto:wsrp-help@lists.oasis-open.org>                            
 List-U <mailto:wsrp-unsubscribe@lists.oasis-open.org>                     
 List-S <mailto:wsrp-subscribe@lists.oasis-open.org>                       
 Delive mailing list wsrp@lists.oasis-open.org                             
 Receiv (qmail 20840 invoked by uid 60881); 20 Mar 2003 12:56:43 -0000     
 X-Spam No, hits=0.0 required=8.0                                          
 In-Rep <3E791717.8000200@oracle.com>                                      
    To: wsrp@lists.oasis-open.org                                          
 MIME-V 1.0                                                                
 X-Mail Lotus Notes Release 6.0 September 26, 2002                         
  From: Rich Thompson <richt2@us.ibm.com>                                  
 Messag <OFCDE43205.9614B3CE-ON85256CEF.00479F6B-85256CEF.0047D37D@us.ibm. 
  e-ID: com>                                                               
  Date: Thu, 20 Mar 2003 08:04:30 -0500                                    
 X-MIME Serialize by Router on D01ML233/01/M/IBM(Release 6.0.1 [IBM]|March 
 Track: 14, 2003) at 03/20/2003 08:04:31, Serialize complete at 03/20/2003 
 Conten multipart/alternative; boundary="=_alternative 0047D30F85256CEF_=" 
 Subjec [wsrp] [wsrp-wsia] [change request #240] Remove                    
     t: 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]