[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor thelp and edit modes
I think many products will make stronger statements than the spec should (e.g. I can see portal implementations that both use SHOULD and MUST for this area). Since there is no driving technical reason the spec needs to recommend one over the other, this is an area the marketplace should decide. Rich Thompson Gil Tayar <Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org lage.com> cc: Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor 12/10/2002 07:34 t help and edit modes AM Hmmm... Then why not mandate Consumer-UI personalization? I personally prefer this over Producer-UI personalization. Answer - each WSRP Producer/Consumer will have their own way of looking at things. I believe that (if WSRP succeeds) we will know which (and whether) one is better than the other only when WSRP is massively used. That's why I'd hate to recommend right now. Gil -----Original Message----- From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] Sent: Tue, December 10, 2002 12:22 To: 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor t help and edit modes Gil, Let me try again then. you write: >I agree. We should not try and mandate the personalization >UI of portlets, or of portals. That is a matter for the >market to decide. My comment: a recipe for chaos in my view. On the issue: I think an entity SHOULD support help and edit mode. But I agree that in practice this SHOULD is likely to degrade to a MAY. My preference would be to not use SHOULD or MAY when faced with implementation choice but to just use a lower case should. regards, Andre -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: 10 December 2002 09:45 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor t help and edit modes Andre, the issue never talked about mandating personalization only under edit mode. There are portals that do that using Consumer-side UI and not under edit mode, and this is covered by the spec. Gil -----Original Message----- From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] Sent: Tue, December 10, 2002 10:53 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor t help and edit modes If we do not mandate personalization is done under a separate mode (edit) then consumer portals can not enforce who has rights to do such personalization or even log such activity. I foresee a lot of very unhappy IT help desks. -- Andre -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: 10 December 2002 05:39 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor t help and edit modes I agree. We should not try and mandate the personalization UI of portlets, or of portals. That is a matter for the market to decide. Gil -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Tue, December 10, 2002 00:00 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor t help and edit modes How is this any different from personalizations today? Portlets can include this throughout their markup, provide unique personalization screens or allow their environment to handle things for it. Business concerns tend to drive developers to make reasonable decisions. There are no technical reasons to require support for just one of these or to elevate one above the others. Rich Thompson Rudnicki Joseph G CONT NSSC To: wsrp-wsia@lists.oasis-open.org <RudnickiJG@NAVSE cc: A.NAVY.MIL> Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY suppor t help and edit modes 12/09/2002 02:35 PM Hello, Others may not think that it is important to include information that demands (or at least encourages) consistent implementations from the user perspective. However, I am not in that group. Having a screen full of portlets from different sources, each of which handles personalization in a different way, would seem to be a nightmare to me. Take care. Joe Rudnicki -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Monday, December 09, 2002 1:24 PM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] Proposed Resolution: An entity MAY support help and edit modes Those actively discussing this issue appear to have arrived at a consensus to change the verbiage regarding optional mode and window state support from "SHOULD" to "MAY". Rich Thompson Carsten Leue <CLEUE@de.ibm.com To: Eilon Reshef <eilon.reshef@webcollage.com> > cc: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, 12/05/2002 03:51 and CAN su pport edit AM I think that the porlet developer should be free to implement any mode he/she wants, do only the VIEW mode should be mandatory, all other modes and states optional (so I prefer the MAY statement). Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 Eilon Reshef <eilon.reshef@web collage.com> To wsrp-wsia@lists.oasis-open.org 12/05/2002 06:20 cc AM Subject RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit And not to beat a dead horse (my favorite activity), RFC2119 also says: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Wednesday, December 04, 2002 1:50 PM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Echoing Eilon's reasoning, is that I would rather let the market decide whether this is a SHOULD or a MAY, and not the WSRP committee. If the market decides it's a SHOULD (i.e. most Consumers will need it, and therefore most portlets will code it), then maybe in one of the following versions we need to rethink the "MAY" decision. If the market decided _against_ it, then we would be glad that we decided to stick by "MAY". I definitely agree with you on the "help"... -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, December 04, 2002 19:41 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Yes ... that is why I said I could be talked into MAY (probably said CAN at the time, but it actually is MAY). On a slightly less abstract level, there are many places where we encourage a behaviour essentially in order to provide more uniform user experiences. That is the essense of why I favor SHOULD ... By the way, whichever way we decide this should also be applied to help, minimized and maximized .... same logic will apply. Rich Thompson "Eilon Reshef" <eilon.reshef@webc To: Rich Thompson/Watson/IBM@IBMUS ollage.com> cc: <wsrp-wsia@lists.oasis-open.org> Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, 12/04/2002 12:29 and CAN su pport edit PM Rich, The challenge I'm having regarding this SHOULD/MAY decision is that typically MUST/SHOULD/MAY refer to a compliant implementation. I agree that a compliant implementation of a portlet SDK SHOULD allow developers to create EDIT mode. However, the situation we're facing in this area (as well as in other areas in the spec), is that we end up putting constraints on the portlet developer. That is, the portlet developer may have perfectly valid reasons for not using EDIT mode (without "understanding the full implications"). Examples that were brought up include lack of need for personalization, but also simple benefit versus cost considerations (e.g., if only 2% of my users configure my portlet, would I spend 20% more development time on this feature or would I rather focus on adding more appealing functionality to the portlet?). Another way to look at it is that technology-wise, implementing EDIT mode is completely optional (MAY). Business-wise, we are trying to drive more people do develop EDIT mode, and hence we want to influence them to spend this extra effort by suggesting it's important. I believe the spec should focus on the technology. That, WSRP-wise, a portlet developer MAY (or may not :-) develop EDIT mode. I.e., Consumers "MUST be prepared to interoperate with another implementation which does not include the (EDIT) option". Although we may want to encourage developers to put EDIT mode, that's a business decision and IMHO me should let our respective companies' marketing department take care of that part of the education. Eilon -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, December 04, 2002 7:53 AM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit RFC2119 defines SHOULD as: "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." while MAY is defined as: "This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)" My argument in favor of SHOULD is that those cases where it makes sense to not implement edit mode need to be carefully thought through. Limitations on deployment and ability of the user to personalize the entity need to be understood before making this choice. The choice is still available, just not completely up to the whim of the developer. Rich Thompson Gil Tayar <Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org lage.com> cc: Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, 12/03/2002 11:58 and CAN su pport edit PM Rich, I totally agree on the must, and the new issues you raised clinch it for me. On the CAN issue, we must not forget that WSIA is in this too. A SHOULD requirement for every portlet to implement state change is a bit heavy on the Producer who just doesn't need that capability. To use your argument - entities with a planned deployment to Consumers who manage their own personalization UI would not need to do this, but nevertheless, the spec recommends them to do so. Gil -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Tue, December 03, 2002 15:54 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit At the Sept F2F in Germany we explicitly made state change independent of mode. Another reason that edit mode can not become a MUST is that we decided Consumer generated UIs for personalization had to be supported by the spec. Entities with a planned deployment to only such an environment should not be required to implement their own UI as well. I could be talked into dropping this level to a CAN, but would resist. While I will argue it can not be required, I also think entity developers should think carefully and develop significant reasons before deciding not to implement edit mode. This is exactly the meaning of SHOULD. Dropping it to CAN would make it totally optional ... I think good reasons are needed when choosing not to implement edit mode (and that they are possible). Rich Thompson Interaction Middleware and Standards for Portal Server IBM T.J. Watson Research Center Yorktown Heights, NY (914) 945-3225 richt2@us.ibm.com "Tamari, Yossi" <yossi.tamari@sap To: wsrp-wsia@lists.oasis-open.org .com> cc: Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, 12/02/2002 01:39 and CAN su pport edit PM Hi Gil, I probably don't understand your question, but the entityStateChange is already in InteractionParams, and I think one of the reasons for this was specifically this use case. If my memory serves me well, Sasha raised this in the F2F in Germany. Where do you see the problem? Yossi. -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Monday, December 02, 2002 8:34 PM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Ouch! So the entityStateChange is relevant for view mode too? The Consumer can't assume that state change won't occur in view mode? -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sap.com] Sent: Mon, December 02, 2002 20:30 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Hi, For 1, my answer is that an entity may support personalization through its view mode (for example by simply remembering the last values a user entered in a text input). Yossi. -----Original Message----- From: Rudnicki Joseph G CONT NSSC [mailto:RudnickiJG@NAVSEA.NAVY.MIL] Sent: Monday, December 02, 2002 6:59 PM To: 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Hello, FWIW. I guess that the questions are: 1. Are we allowing personalization for an entity that doesn't support the Edit mode (if so, how)? 2. Are there other reasons, not personalization, for supporting an Edit mode? Take care. Joe -----Original Message----- From: Gil Tayar [ mailto:Gil.Tayar@webcollage.com] Sent: Monday, December 02, 2002 11:58 AM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Let's go that route - Edit mode is defined (5.10.2) as "[providing] content and logic that let a user customize the behavior of the entity". Let's define personalization as "enabling the user to customize the behavior of the entity". Thus, the sentence "the entity MUST support edit mode if it allows personalization" becomes "the entity MUST support content and logic that let a user customize the behavior of the entity if it enables the user to customize the behavior of the entity". The expanded sentence above is almost a tautology, except for the fact that entities may enable customization of their behaviors out-of-band. Thus, an entity that enables the user to customize the behavior of the entity out-of-band may want NOT to support WSRP content and logic that does the same (i.e. edit mode), for various reasons. So, given the above precise definitions, I still think this is a SHOULD. Gil -----Original Message----- From: Rudnicki Joseph G CONT NSSC [mailto:RudnickiJG@NAVSEA.NAVY.MIL] Sent: Mon, December 02, 2002 18:35 To: 'Gil Tayar'; wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Hello, It would seem that we have to describe what the edit mode is for (personalization?) in unambiguous terms somewhere. Sometimes, I am a bit afraid that we are using a lot of "SHOULDS" to cover uncertainty and ambiguity when it is up to us to know (or at least act like we know) the right answer. Thoughts? Take care. Joe Rudnicki -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Monday, December 02, 2002 11:09 AM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit A MUST of this sort would need to really describe what "personalization" is, and I wouldn't want to go to that route! With a SHOULD, I think we can go with a vague definition of "personalization". -----Original Message----- From: Rudnicki Joseph G CONT NSSC [mailto:RudnickiJG@NAVSEA.NAVY.MIL] Sent: Mon, December 02, 2002 17:55 To: 'Tamari, Yossi'; wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit Hello, Perhaps, "...MUST support edit mode if it allows personalization?" Take care. Joe -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sap.com] Sent: Sunday, December 01, 2002 1:18 PM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN su pport edit I second this. Many entities simply do not have (need) an edit mode. A "Top business news" portlet may not be personalizable. Maybe the wording should be "... SHOULD support edit mode if it allows personalization". Yossi. -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Sunday, December 01, 2002 1:13 PM To: wsrp-wsia@lists.oasis-open.org Subject: [wsrp-wsia] [I#164] An entity SHOULD support help, and CAN support edit Issue: 164 Status: Active Topic: interface Class: Minor_Technical Raised by: Gil Tayar Title: An entity SHOULD support help, and CAN support edit Date Added: 1-Dec-2002 Document Section: v0.85/5.10 Description: In v0.85, an entity SHOULD support both edit and help. I think SHOULD for edit is too strong a recommendation, as it puts a fantastic burden on the portlets. As Help is very simple to implement, I think the wording should be changed to: "an entity SHOULD support help, and CAN support edit". Gil Tayar WebCollage ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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] | [Elist Home]
Powered by eList eXpress LLC