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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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


Subject: Re: [wsrp-wsia] [change request #229] wsrp-mode & wsrp-windowStat eprocessing


I agree, the SHOULD shouldn't become a MUST.  The Consumer should be 
free to interprete the intent of Portlet and choose an appropriate 
Mode/WS.  For example if the consumer is managing a stack of MODES the 
user has currently entered -- say they are in HELP mode by way of EDIT 
mode by way of VIEW mode, I think the Consumer should have the 
flexibility of forcing an unwinding of the stack [to provide a 
consistent UI to its users].  I.e. if a portlet requests VIEW mode in 
returning from HELP the portal "rejects" this choosing instead to return 
them to EDIT mode.  [Note: in this example its assumed that VIEW mode is 
not indicated as an allowed MODE once HELP is entered].
      -Mike-

Eilon Reshef wrote:

>Rich,
>
>1. Is the first part verifiable?
>
>"The Consumer MUST process all mode and window state change requests and
>either honor or reject them 
>prior to invoking the operation."
>
>2. Why is the second part needed?
>
>"If the requested mode or windowState change is for an invalid or
>unavailable mode or windowState (e.g. policy 
>prohibits this End-User from entering that mode), the Consumer MUST leave
>the current value unchanged."
>
>That is, why do we explicitly prohibit Consumer from (for example) mapping
>all unknown modes to maximized (i.e., "just to be on the safe side")?
>
>Eilon
>
>-----Original Message-----
>From: Rich Thompson [mailto:richt2@us.ibm.com] 
>Sent: Thursday, March 06, 2003 14:36
>To: wsrp-wsia@lists.oasis-open.org
>Subject: [wsrp-wsia] [change request #229] wsrp-mode & wsrp-windowState
>processing
>
>
>Document: Spec
>Section: 10.2.1.1.1 & 10.2.1.1.2 & 10.2.1.4 & 10.2.1.5
>Page/Line: 59 
>Requested by: Rich Thompson
>Old text: The Consumer MUST process all mode and window state change 
>requests and either honor or reject them prior to invoking the operation. 
>Old text: If the requested mode change is for an invalid or unavailable 
>mode (e.g. policy prohibits this End-User from entering that mode), the 
>Consumer SHOULD leave the current value of the mode unchanged.
>
>New text: [move statement to 10.2 and reword] The Consumer MUST process 
>all mode and window state change requests and either honor or reject them 
>prior to invoking the operation. If the requested mode or windowState 
>change is for an invalid or unavailable mode or windowState (e.g. policy 
>prohibits this End-User from entering that mode), the Consumer MUST leave 
>the current value unchanged.
>
>Reasoning: These conformance statements appears at least 4 times. Lets 
>move them up to the enclosing section and have it apply to all as a single 
>statement. Also change the SHOULD to a MUST.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>  
>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




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