OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[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