[wsrp-wsia] Issues resolved (12-Dec-2002 & 5-Dec-2002)

Please 
comment on the correctness of the resolutions below, especially the 5-Dec ones 
(I seemed to have mislaid my list of resolved issues from that phone 
call)

 

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: new name ==> portlet 
entity

 

Issue: 155 

Status: Resolved
Topic: interface
Class: Minor Technical
Raised by: Michael 
Freedman
Title: 
12-Dec-2002 Rename 'FAULT' entityStateChange flag
Date Added: 
24-Nov-2002
Document Section:   v8.5/5.3.3
Description:
With 
the reworked semantics of the entityStateChange flag 'FAULT' no longer seems an 
appropriate name.  Read-only might be a better name -- or something 
else.  This is because it seems to direct the producer to not allow writing 
but doesn't define any semantics for the consumer to follow up if the producer 
really wanted to do the write.
Resolution: entityState="ReadOnly", 
"ReadWrite" and "CloneBeforeWrite"

 

Issue: 158
Status: 
Resolved
Topic: interface
Class: Minor 
Technical 
Raised by: Gil 
Tayar   
Title: sessionHandle and entityInstanceID 
size
Date Added: 1-Dec-2002
Document Section:   
v0.85/5.1.1 & 5.1.2
Description:
"entityInstanceID should be of a 
maximum size of <256 as it is a string passed to the Producer, and which the 
Producer may want to use as a key. This is exactly like entityHandle and 
registrationHandle, which the Consumer may want to use as a database key, and 
thus is restricted to <256. A rename to consumerEntityInstanceHandle may 
indicate its use better and also restrict it to a 256 character length 
limit.
, on the other hand, does not refer to anything in the spec, and is 
just an opaque string that the Producer uses to store information on the 
Consumer side, just like entityState or registrationState. Thus, the limit of 
256 on its length is not neccesary. A rename of sessionHandle to sessionState 
may indicate its use better and also remove the 256 character length 
limit."
Resolution: 4K limit for sessionHandle.

 

Issue: 
161
Status: Resolved
Topic: interface
Class: 
Technical
Raised by: Gil Tayar
Title: tri-state 
usesMethodGet
Date Added: 1-Dec-2002
Document 
Section:   v0.85/7.1.2
Description:
usesMethodGet today means - 
I have it or I don't. I would like to add a new one, which says I'll use 
methodGet only if the Consumer supports it, otherwise I'll fall back on other 
methods. This enables the Producer to support all 
Consumers.
Resolution: drop the tri-state, and let the Consumer 
define whether it supports method=get in the meta data sent in the reg 
interface

 

Issue: 163
Status: 
Resolved
Topic: interface
Class: Technical
Raised by: Gil 
Tayar
Title: Restructure performInteraction and performBlockingInteraction 
responses
Date Added: 1-Dec-2002
Document Section:   
v0.85/v5.4
Description:
"Today, the connection between the responses of 
these two operations is implicit. If you look at the signature you will in the 
end understand that they are similar, except for some fields that may be 
returned by performBlockingInteraction and not by performInteraction.
believe 
this difference to be important, as it highlights the difference between the two 
operations. Thus, it should be made explicit.
The way to do this is to make 
the blockingInteractionResponse hold an interactionResponse, plus, as sibling 
fields, those fields that are allowed only in the 
blockingInteractionResponse."
Resolution: accepted, but with the 
UpdateResponse still there to make it exclusively or-ed with 
redirectURL

 

Issue: 166
Status: 
Resolved
Topic: general
Class: Minor
Raised by: Editorial Gil
Title: 
Tayar   Remove the section on load balancing
Date Added: 
1-Dec-2002
Document Section:   v0.85/5.7
Description:
Remove 
this section, or at least move it to the introduction. The requiresInitCookie, 
although motivated by load balancing concerns, may be used for other purposes, 
and thus should not be tied anymore to load balancing. Load-balancing 
considerations are definitely OK in a non-normative introduction, but not in the 
normative spec
Resolution: Move to introduction

 

Issue: 
167
Status: Resolved
Topic: interface
Class: Minor Technical 
Raised by: Gil Tayar
Title: userContextID should 
not be a required field
Date Added: 1-Dec-2002
Document 
Section:   v0.85/4.1.8
Description:
The Consumer may not "have" 
a user, and thus the userContextID should be optional
Resolution: 
make the whole userContext nillable

 

Issue: 
168
Status: Resolved
Topic: interface
Class: Minor Technical
Raised by: Gil Tayar
Title: Make wsrp-navigationalState 
required
Date Added: 1-Dec-2002
Document Section:   
v0.85/9.2.1.2
Description:
"In section 9.2.1.2 it is written ""If this 
parameter is missing, the Consumer MUST send the current navigational state"". 
This effectively forces a Consumer that stores the navigationState in the URL 
(for example, a stateless Consumer) to also store the previous navState on the 
URL so that it can be used if the Producer did not send a navState!
propose 
changing it to: ""the Producer SHOULD send the navState to the Producer. If this 
parameter is missing, then the new navState is an empty 
string."""
Resolution: 
still optional, but if not there, it means empty navigationalState to the Consumer

Gil Tayar

WebCollage