[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC