[wsrp-wsia] Preliminary Issues agenda for 10/17

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

1. Issues moving from tentative resolution to resolved:

2. Items scheduled for a vote from 10/10

3. (#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."

4. (#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? ...

5. (#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?

6. (#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?

7. (#51) Define a naming schema 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".

8. (#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.

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

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

11. (#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?