[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'm glad it does not look like we are going to need to vote on whether to mandate UI personalization. It is premature in the extreme and while the industry is certain to throw up myriads of samples overnight, the fact is that until we see what the likely shakeout for widespread single-sign-on security for individual identity authentication, authorization and certification will be, it doesn't make sense. Also there is already an OASIS UIML TC getting underway, and HumanML will be offering a standard vocabulary that will be useful in this area as well. HumanML will also harmonize standard vocabularies for names, addresses, medical history, employment, education and other more or less automaticially update-able if not updated, individual histories across such areas as Customer Information Quality, HR-XML and public safety/law enforcement as well as personalization preferences profiles authorized by and authenticated by individuals, beyond the basics of standard security authentications for simple identity. This will set the stage for software applications capable of adapting to personalization profiles, and continuing to learn the licensed user for the life of the product. Ah, there's nothing quite like the smell of unbridled speculation first thing in the morning! Ciao, Rex At 7:45 AM -0500 12/10/02, Rich Thompson wrote: >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> > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> -- Rex Brooks Starbourne Communications Design 1361-A Addison, Berkeley, CA 94702 *510-849-2309 http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC