[wsrp-wsia] Issues for 12/5 call

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

There have been several issues appear over the past week on the email list
(I am finally reading them). Lets work through:

#160: Template fields should camel lower casing
     => Had been noted by others as well ... current version uses
actionTemplate ...


#161: 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.
     => proposal is to:
           1. add Consumer metadata - "methodGetSafe" (boolean)
           2. make usesMethodGet triState - add value for
"adaptsToConsumer"
   => If the first boolean is added, doesn't the second just become
equivalent of dynamically returning Consumer.methodGetSafe for
usesMethodGet?


#159: In all cases where locale/language needs to be specified, this should
be optional. In some cases, I just don't know what the locale is. Even HTTP
allows not specifying locale.
      => LocalizedString is the one case where I don't think this should be
optional.


#163: Make is clear that BlockingInteractionResponse includes everything
InteractionResponse does.
     => Two possibilities:
            1. Additional verbiage in the text.
            2. Explicitly include an InteractionResponse in an
UpdateResponse
   => If we want to make this more explicit, I would favor #2.


#162: OperationNotSupportedOnThisNavigationalStateFault Needed
Description:
Some Producers may use only performInteraction, or only
performBlockingInteraction, or just use getMarkup. Or maybe some Producers
support performInteraction only on some navstates,
performBlockingInteraction on others, and getMarkup on yet others. There is
no way to return a fault that indicates this
    => Use case for when the entity-supplied navState can't be used with
the entity-declared operation?


#158: Length of sessionHandle (rename to sessionState and remove length?)
      => This is the one handle whose size people most wanted to restrict
at the Nov F2F


#158: Length of entityInstanceID (rename consumerEntityHandle and impose
length?)
      => I would not rename this a handle as it is not a remote reference.
Do we want to impose the same length restrictions on it as on handles? I
think this is likely a good idea as the Producer (or entity) is likely to
use this as a key.


#???: navigationalState in InteractionResponse? (question Gil raised)
This field should not be included in InteractionResponse as:
1. this response is returned by performInteraction.
2. Some consumers may want to redirect to a new Consumer URL based on this
navigationalState.
3. performInteraction can be called by the Consumer after returning markup
to the end user, and thus it may be too late to redirect
   => performInteraction carries the semantics that the entity does not
require the Consumer to block ... the Consumer may choose to block
streaming output to the client for other reasons (such as the redirect
mentioned), but that is independent of the entity. I think it is important
that the logical action implied by a call to performInteraction be able to
modify navigationalState ... otherwise developers will find this call
rarely useful and will always code urls to be BlockingActions.


#165: The Consumer should not strip the namespace prefix from form
parameters
Description:
"Quoting from the spec: ""If namespace encoding is used for form parameters
or other data the entity receives as in markupParams, then the Consumer
MUST strip the namespace prefix from the parameter names before passing
them to the Producer"".
believe the Consumer should not do this for two reasons:
1. It now means that the Consumer has to understand the uploadData and
recognize one of the mime types, specifically
application/x-www-form-urlencoded. This is definitely not generic.
2. The Producer will anyway have to understand namespace prefixing,
including using it in JavaScript client code, so its not that big of a
chore for the Producer to do this (for example, by adding another form
parameter which includes the prefix code)."
     => Not sure when this came in or its rationale ....


#166:Remove the section on load balancing
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


#167:userContextID should not be a required field
Description:
The Consumer may not "have" a user, and thus the userContextID should be
optional


#168:Make wsrp-navigationalState required
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."""



Rich Thompson
Interaction Middleware and Standards for Portal Server
IBM T.J. Watson Research Center
Yorktown Heights, NY
(914) 945-3225
richt2@us.ibm.com