[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues resolved (12-Dec-2002 & 5-Dec-2002)
Deltas from my minutes taken on 12/05 3. issues #160 solved: use camel lower casing #161 solved: add Consumer meta data field: "methodGetSafe", no need for tristate->drop #159 solved: optional except for two cases: LocalizedString, ResourceValue #163 agreed to explicitly include InteractionResponse in an UpdateResponse. Rich send's proposal to list to let people look into it. Hopefully this one can be resolved by email. #162 soved: no explicit fault type, one can put this in the fault detail of OperationFailed fault #158a solved: agreed to encourage people to choose small sizes for sessionID. Limit size to 4K. #158b solved: rename to ConsumerEntityKey, limit size to 256. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | Rich | | | Thompson/Watson/I| | | BM@IBMUS | | | | | | 12/12/2002 07:08 | | | PM | | | | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsrp-wsia@lists.oasis-open.org | | cc: | | Subject: Re: [wsrp-wsia] Issues resolved (12-Dec-2002 & 5-Dec-2002) | | | | | >--------------------------------------------------------------------------------------------------------------------------------------------------| Deltas from my notes: #158: 1) rename sessionHandle to sessionID and restrict to 4K bytes and 2) rename entityInstanceId to entityInstanceKey and restrict to 255 bytes. #159: xml:lang only required for LocalizedString and ResourceValue #160: use first lower camel casing for template fields #162: use OperationFailed fault with explicit reason field #164: Drop conformance statements about optional modes and window states Rich Thompson Gil Tayar <Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org lage.com> cc: Subject: [wsrp-wsia] Issues resolved (12-Dec-2002 & 5-Dec-2002) 12/12/2002 12:54 PM 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 ---------------------------------------------------------------- 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