Re: [wsrp-wsia] Issues Resolved in 7-Jan-2003 call

[Rich Thompson <richt2@us.ibm.com>]

deltas (mostly #179) from my notes are intertwined with <rt/>

Rich Thompson




Gil Tayar <Gil.Tayar@webcollage.com>
01/08/2003 02:15 AM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        [wsrp-wsia] Issues Resolved in 7-Jan-2003 call


[I#154] rename "entity" to "portlet" or "portlet type"
Issue: 154
Status: Resolved
Topic: general
Class: Technical
Raised by: Eilon Reshef
Title: rename "entity" to "portlet" or "portlet type"
Date Added: 7-Nov-2002
Document Section: 
Description:
As the word "entity" is too general, and because we have finally given a 
name to the thing that we are "showing", why not rename entity to 
"portlet" or "portlet type"
Resolution: portlet & Producer configured-portlet/Consumer 
configured-portlet where the distinction is necessary
 
[I#169] Does refresh page (F5/Ctrl+R) re-invoke 
performBlockingInteraction?
Issue: 169
Status: Resolved
Topic: interface
Class: Technical
Raised by: Gil Tayar
Title: Does refresh page (F5/Ctrl+R) re-invoke performBlockingInteraction?
Date Added: 1-Dec-2002
Document Section:   v0.85/everywhere
Description:
This is not indicated anywhere in the spec
Resolution: It's up to the Consumer. Information on this will be added to 
the spec and the primer.
 
[I#170] Scope of Producer-Consumer HTTP session
Issue: 170
Status: Resolved
Topic: interface
Class: Minor_Technical
Raised by: Yossi Tamari
Title: Scope of Producer-Consumer HTTP session
Date Added: 4-Dec-2002
Document Section:   v0.85/3.13
Description:
"In the Transport Issues section of the spec it says: ""Consumers that 
manage transport layer issues, such as cookies, MUST return them to the 
Producer only for subsequent invocations using the same userContext."".
, since the userContext may change because the user's role/profile has 
changed, but he is still in the same session, so the same cookie should 
still be sent. On the other hand, the user may have logged out of his 
portal (closed his browser) and logged in again, but normally his user 
context hasn't changed. In this case there should be no requirement to 
send the cookie (it is a new user session, and a new load-balanced 
instance may be used).
I think the scoping here should be to the consumer's concept of 
user-session rather than to the userContext."
Resolution: The maximum scope is the scope of the Consumer client's 
logical session (and being vague about what a session is)
 
[I#175] Roles should be per-Entity and not per-Producer
Issue: 175
Status: Resolved
Topic: interface
Class: Technical
Raised by: Eilon Reshef
Title: Roles should be per-Entity and not per-Producer
Date Added: 10-Dec-2002
Document Section:   v0.85/4.1.7
Description:
RoleDescription[] - should it be per each Entity and not per Producer? The 
current model only supports roles per Producer which works when the 
Producer is a centralized portal environment, but makes it much harder to 
manage and deploy changes in less controlled environment. For example, 
this means that if a development environment allows portlet developers to 
define custom roles per portlet (e.g., if one Producer may span multiple 
web-apps in J2EE), then the Producer must continuously accumulate all 
roles from all its portlets to present a coherent role list. And, the 
Consumer needs to sample that list more often to ensure that there are no 
changes. Another example is how would an application-level-WSRP-proxy 
support multiple services with different roles?
Resolution: Leave it as it is
 
[I#179] 7-Jan-2003  requestParameter semantics unclear
Issue: 179
Status: Resolved
Topic: interface
Class: Minor_Editorial
Raised by: Eilon Reshef
Title: requestParameter semantics unclear
Date Added: 10-Dec-2002
Document Section:   v0.85/5.1.6
Description:
"requestParameters: I am not sure what the intent of this variable is.
it can mean three different things:
1. Data items passed as part of the action URL - this seems redundant as 
the Producer can easily use navigationalState.
2. Data items passed as <form method=get> submit? Is this indeed the case?
3. Data items passed as <form method-post> submit? Is this indeed the 
case?
Note that (2) and (3) are accessed using the same API in J2EE but not in 
ASP, so if the intent is also for (2) and (3) then we may need to 
differentiate."
Resolution: Add an interaction parameter - wsrp-interactionState relevant 
to Interaction actions, which is to be passed only to perform*Interaction. 
Remove requestParameters.
<rt>
 - Rename requestParameters as formParameters and move to 
InteractionParams (getMarkup can not take these) [resolution of #187 may 
impact this]
 - Add interactionState (transient input to action processing) to 
interactionParams (& cooresponding interaction parameter) to replace 
current requestParams, queryString is not how they pass this extra data.
 - Add words to effect that navigationalState reflects how to regenerate 
the page, interactionState reflects input to perform*Interaction().
 - Add words around what navigationalState to use when returning markup 
from BlockingInteraction.
 - Add words about Consumer's processing URL activation
</rt>
 
[I#181] registration changes
Issue: 181
Status: Resolved
Topic: registration
Class: Technical
Raised by: Eilon Reshef
Title: registration changes
Date Added: 10-Dec-2002
Document Section:   v0.85/6.*
Description:
"Currently, registration serves two purposes:
. To register a particular system (technical characteristics such as 
Consumer version)
2. To register an entity collection (business characteristics: when 
de-registering, the entities die)
 
This duality is not only confusing, but also explicitly prohibits useful 
business scenarios such as:
[I#The ability to use multiple portal systems within an organization with 
the same personalization characteristics] The awkwardness doesn't buy us 
much, and each one of the following approaches solves the problem without 
much sacrifice:
1. The ability to use multiple portal systems within an organization with 
the same personalization characteristics
2. The ability to use portal systems of different versions (e.g., v3.2 and 
v3.5) for different environments (development versus production), while 
both using the same entities
Etc.
This will force WSRP to invent unnatural workarounds such as explicit APIs 
for moving and possibly synchronizing entities between registrations.
The awkwardness doesn't buy us much, and each one of the following 
approaches solves the problem without much sacrifice:
 
1. Eliminating registration API, Consumer technical characteristics move 
to other operations
 
With this approach (which had been discussed in the past), registration 
becomes out of band. That is, the Producer may supply a URL where Consumer 
administrators come in, enter any data, and eventually receive a 
registrationKey, which they plug into their systems. To unregister, they 
return to this URL and manually unregister.
 
To supply the Consumer technical characteristics, a new structure (e.g., 
ConsumerSystem) has to be passed in the other API calls whenever 
registrationKey is passed today.
 
2. Leaving registration API, using it for Consumer technical 
characteristics only
 
With this approach, registration API stays as-is. However, the spec would 
no longer specify that an Entity ""belongs"" to a certain registration or 
a registration scope. That is, the same entity can be reused across 
multiple registrations. This probably means that the registration should 
be called registerConsumerSystem.
 
This alleviates the need for modifyRegistration, since the Consumer can 
always register a new system on its behalf.
 
3. Leaving registration API, using it only for the business 
characteristics
 
With this approach, registration API remains, but the technical 
characteristics are being moved into a separate structure called 
ConsumerSystem, which is transferred on every API call, whenever 
registrationKey is passed today.
 
The Entities are still managed under the registration scope, but the 
Consumer may use multiple systems under this registration. There is still 
a need for modifyRegistration in case some business parameters (e.g., 
credit card) change.
 
4. Separating registration API into two APIs: one for business and one for 
technical
 
With this approach, two APIs are introduced:
 
registerConsumerSystem - registers the technical characteristics (Consumer 
version, etc.).
registerConsumer (or registerConsumerOrganization or 
registerEntityManagementScope) - registers the business characteristics 
(properties).
 
Both keys would be passed on every API call. This would still allow 
multiple physical systems under the same registration and vice versa.
 
IMHO, all the above options represent a better model of real-life 
situations compared to the existing model which seems to be flawed.
"
Resolution: registration is still in. It was decided not to rely on it to 
pass Consumer information that is essential to the portlet using this 
mechanism.
 
[I#183] markup charset different or the same as the XML response charset?
Issue: 183
Status: Resolved
Topic: interface
Class: Technical
Raised by: Gil Tayar
Title: markup charset different or the same as the XML response charset?
Date Added: 9-Jan-1900
Document Section: 
Description:
It is not clear from the spec whether the charset of the markup can be 
different from the XML response charset. I think that in the F2F we 
decided that it should be the same, but opinions vary. If they are the 
same, then the spec should be altered somewhat. If they can be different, 
what does it mean? How can I return a UTF-16 character set markup inside a 
SHIFT_JIS response? Is there any meaning at all for this?
Resolution: They are the same, except when using attachments. The editors 
should state this in the spec.
<rt>
  There is a statement to this effect in the definition of MarkupContext, 
but conflicting statements elsewhere ... rationalize them all.
</rt>
 
[I#184] can performInteraction return new navigationalState?
Issue: 184
Status: Resolved
Topic: interface
Class: Technical
Raised by: Gil Tayar
Title: can performInteraction return new navigationalState?
Date Added: 12-Dec-2002
Document Section:   v0.85/5.3.1
Description:
-
Resolution: No, it cannot return new navigationalState
 
[I#185] Remove concept of Roles from the spec
Issue: 185
Status: Resolved
Topic: interface
Class: Technical
Raised by: Rich Thompson
Title: Remove concept of Roles from the spec
Date Added: 15-Dec-2002
Document Section:   v0.85/various
Description:
"Roles as they exist in the current draft are assertions by the Consumer 
of the access controls that should be applied for this invocation by both 
the Producer and entity. As such they potentially restrict access both to 
the functionality of the Producer and the content afforded by an entity. 
WSRP is not the right place for defining how a web service and its client 
jointly determine the security context for a particular invocation, but
specs such as WS-Security, SAML, XACML, JSR109, ... provide the relevant 
definitions. As a result, I think that roles do not belong being defined 
by WSRP."
Resolution: Rename "role" to "userCategory".