[wsrp-wsia] Issues agenda for 10/17

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

1. Issues moving from tentative resolution to resolved (for information
only):
 (#01) No need for discussion of SOAP Proxy's
     -Rewriting the Introduction section to focus more on introducing the
concepts of the specification
 (#03) Make all cross-references to requirements Document: a footnoted
hyperlink
     - Requirement references are all now hyperlinks
 (#04) Make an appendix that pulls together all the requirement statements
     - First pass at this was effectively unusable ... reasonable, but not
useful idea => drop it
 (#09) Insert subsections that describe the usage of data structures
     - Interface sections have a new format that first introduces any new
data
structures and then discusses the operations
 (#10) Collapsing consumerState into consumerHandle
     - The handle is not allowed to change in modifyConsumer() while this
field may. This was to simplify processing for the Consumer. Descriptions
of handles tightened up to indicate they are invariant once created.
 (#14) Should the spec describe relationship to UDDI?
     - UDDI mapping sections removed
 (#21) More verbiage on why no release on initEnvironment
     - Verbiage around usage of initEnvironment() has been added
 (#23)Adding clientParameters to getMarkup operation
     - ClientParameters as an array of querystring, transport headers
and/or Consumer supplied data is now part of MarkupParams.
 (#25) Could this be renamed markupRequest? Likewise for interactionContext
     - These two structures have been renamed MarkupParams and
InteractionParams.
 (#27) Missing mapping of statefulness needs to the operations
     - Tables to provide the mapping for the relevant data fields have been
added.
 (#28) CONFIG mode is optional under JSR-168
     - Description of CONFIG mode has been added.
 (#29) DESIGN mode has no equivalent under JSR-168
     - DESIGN mode has been deleted ... could not come up with a good
description for it.
 (#30) PREVIEW mode has no equivalent under JSR-168
     - Description of PREVIEW mode has been added.
 (#31) MINIMIZED state does not necessarily mean no markup
     - Needed to modify this passage because in some circumstances the
portlet might need to write into the output stream even if minimized. This
is e.g. the case for Portlets rendering VoiceXML or for portlets that want
to display some sort of status bar in minimized mode. JSR168 will change
this accordingly
 (#33) propertyDescription structure missing from chapter 11
     - PropertyDescription is now section 6.1.10
 (#34) Do we want to define how an entity sends a title to the portal?
     - Yes. We do. We added a "preferredTitle" field in the markupResponse
 (#35) Is recommend strong enough for using non-ascii encoding conventions
defined in this section?
     - In the September F2F it was decided to make all URL-s UTF-8 encoded,
and thus recommend is not strong enough. It is now a MUST!
 (#39) Does the example help to understand relationship between producer
and consumer URL rewriting?
     - This portion was rewritten
 (#40) Move URL Writing Semantics earlier
     - Semantics regarding which party does the URL writing has moved into
the intro section of the discussion.
 (#43) Why no previousWindowState in RequestContext?
     - previousWindowState and previousMode fields have been replaced with
constants to request the Consumer switch to the previous state/mode
 (#44) Rename "expires" to "sessionExpires" in ResponseContext
     - Structure and field have been renamed to reflect change to refHandle
proposal
 (#52) How should we organize use cases
     - hyperlink to Use cases from the Introduction section.
 (#53) Define a use case for previous mode?
     - previousWindowState and previousMode fields have been replaced with
constants to request the Consumer switch to the previous state/mode
 (#57) Unification of session and entity handles?
     - F2F decision to try this reflected in current draft. Resolve as
'Yes'.
 (#71) What's the difference between DESIGN MODE and CONFIG MODE
     - DESIGN mode has been deleted ... could not come up with a good
description for it.
 (#72) Markup - Can Links directly point to getMarkup ?
     - Yes, urlType=Render. See section 9.2.1.6.2
 (#73) userContext - optional or mandatory mixup in text
     - Rewritten as part of splitting getDescription() into 2 operations.
 (#74) Should the Consumer MAY or MUST releaseHandles?
     - Modify v0.7 language to say the Consumer MUST attempt to release
these handles. Network failures should be retried at least 10 times with at
least 1 hour between attempts.
 (#75) How to ensure consumerName is unique?
     - Eliminate requirement statement, encourage uniqueness and suggest
the Consumer's URL as such a name.
 (#78) should we specify storage of consumerHandle?
     - Language was updated to eliminate discussion concerning whether or
not the Consumer persists handles to focus on releasing them at the end of
their lifecycle management. Draft v0.7 incorporates the suggestion to
remove language about different Consumer implementation choices.
 (#79) Why return consumerHandle in modifyConsumer's consumerContext?
     - New structure (RegistrationCore) introduced to eliminate possibility
of this error
 (#80) cloneEntity and modification of properties - in same call?
     - This optimization has been eliminated. Draft v0.7 eliminates this
piggybacked properties parameter as per F2F decision
 (#82) What is the need of previousMode?
     - previousWindowState and previousMode fields have been replaced with
constants to request the Consumer switch to the previous state/mode
 (#85) sessionID/expires MUST/MAY contradiction
     - Language modified to "The Consumer MUST use this new value as the
refHandle on subsequent invocations until either the Producer supplies
another newRefHandle or either a fault message from the Producer or the
refHandleExpires duration indicates that the refHandle is no longer valid.
Note that failures to use this handle on subsequent invocations (e.g.
something exceptional caused the Consumer to lose track of it) will result
in a loss of state and likely unexpected behavior for the End-User."
 (#88) Producer URL Writing section is confusing
     - First pass at a BNF-like notation added
 (#89) Consumer URL Writing section is confusing
     - First pass at a BNF-like notation added

2. (#26) Would an isRefresh flag on getMarkup be useful?
 - This flag has been proposed as a means to distinguish between an initial
call on a render URL and a later call to getMarkup() (could be either an F5
refresh or due to an interaction with another entity on the page). Use case
for this is supporting entities using the JSP or servlet processing model
(ie. single phase) ... JSR168 is discussing this at their F2F ... it was
pointed out that this is a back door to state changes in getMarkup() that
likely breaks many other decisions we have made.

3. (#94) getMarkup() able to modify/return state
- Draft v0.7 has the semantics that getMarkup() only renders the current
state. I have heard that JSR168 would like this changed to allow returning
modified state. Other proposals include local state modifications only.
Would proponents of changing the semantics currently in the draft post an
email with the proposal, a description of how it is safe against page
refreshes (including bookmarked pages) and important use cases that would
be enabled by the change in semantics.

4. (#6) Is groupID required?
 - Ongoing discussion on the semantics of this parameter. Need to arrive at
a conclusion ....

5. (#92) Maximum size of a handle
 - Ongoing discussion, need to arrive at a conclusion ....

6. (#84) More than a boolean in secureClientCommunications?
 - Sasha pointed out that it may be useful to know the level of security
applied to the End-User/Consumer connection regardless of the number of
hops ...

7. (#96) Review well known URL parameter names
 - Draft v0.7 has (are other needed?):
    wsia:navigationalState - sets this for the entity
    wsia:mode - requests a mode change before invoking the entity
    wsia:windowState - requests a windowState change before invoking the
entity
    wsia:urlType - describes how to process the activation of this url
    wsia:url - the url of a resource for when wsia:urlType=Resource
    wsia:token - the token for namespacing when wsia:urlType=NameSpace
    wsia:secureURL - specification that the rewritten url should use secure
communications
    wsia:rewriteResource - flag indicating whether the Consumer must parse
the indicated url for url rewriting
    wsia:clientParameters - Producer url writing place to put arbitrary
clientParameter list
    wsia:refHandle - Producer url writing place to place refHandle for the
resulting invocation.

8. (#18) Mandating the use of initEnvironment if Producer needs it
 - Draft v0.7 has the following in the description of initEnvironment: "If
the Producer's metadata has set the doInitEnvironment flag to true, then
the Consumer MUST invoke initEnvironment() once for the groupID prior to
invoking getMarkup() for this End-User for any entity using the same
groupID."

9. (#24) Adding previousWindowState to getMarkup operation
 - Draft v0.7 removed these fields & defined semantics for a
previousWindowState constant. Do we want those semantics? Require entities
to manage this themselves? ...

10. (#42) Why does consumer need to tell producer which extended attributes
it supports?
 - Do we need to add explicit verbiage to the effect that a producer/entity
may tailor its requested items (e.g. userProfileItems) based on the
information the Consumer supplies at registration time?

11. (#45) Signaling state change in InteractionResponse
 - The description of navigationalState tries to capture that a null return
value means continue using the old value. Is the wording clear? Same
verbiage needed for entityState? How does this interact with
interoperability issues with using nillable?

12. (#51) Define a naming scheme how WSRP binding tModel are named
 - Proposal from email list is "SPEC_VERSION_FACTOR_WSDLTYPE_TYPESPECIFIC"
which would lead to names like "WSRP_v1_Markup_Binding_SOAP".

13. (#93) Payload extensibility mechanism
 - The F2F decided to explore using <any/> for this as it is the natural
mechanism in a schema based system and provides for backward compatibility
for future versions. On the technical level, has this worked? On the
philosophical level, is it still the way we want to proceed?

14.  (#97) Caching mechanism
 - Draft v0.7 has timeout and coarse scale keys defined for caching
mechanism. This does not include the ability to invalidate other markup
from the same Producer. Introducing InvalidationKeys could add this
feature. Do we want to include this in v1.0? Followon to discussion of
ValidationKeys of InvalidationKeys?