[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]