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

[Gil Tayar <Gil.Tayar@webcollage.com>]

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