Re: [wsrp-wsia] Issues agenda for 10/24

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

This week's agenda is essentially a continuation of last week, though there
are a different set of issues moving to resolved unless objections are
raised.

1. Issues moving from tentative resolution to resolved (for information
only):
 (#12) Splitting getEntityDescription for different handles
     - done as per Sept. F2F
 (#13) Splitting getEntityDescription into functions with explicit return
types
     - done as per Sept. F2F
 (#15) Enabling cloneEntities on producers that do not need registration
     - withdrawn
 (#17) Defining whether initEnvironment is supported via metadata
     - initEnvironment() is in Markup factor with Producer metadata
declaring need for usage - as per Sept. F2F decision
 (#20) Is entityState (a persistent state) necessary for v1?
     - Yes. It is required for Consumer-stored entity state
 (#22) What is the rationale behind returning successfully released
handles?
     - releaseHandles was split into two operations, both which return
either void or a fault
 (#32) Do property operations need to be included in base?
     - Yes. The Sept F2F declared that persistent properties for entity
configuration are to be included in v1.0.
 (#48) Should an item state that it is cloneable?
     - No entity metadata in v1.0 regarding whether it can be cloned …
Producer managed area.
 (#49) Problem in the the use of multiple description records that derive
from each other
     - getDescription was split into two functions. See Issue #12 and Issue
#13
 (#54) WSRP session to consumer – end user session
     - Gil's proposal accepted - Specify “WSRP session between consumer and
producer maps to end user session of the consumer” – what end user session
means depends on the consumer.
 (#55) Shall we have a registerConsumer operation in the 1.0 spec or out of
band ?
     - While out of band is allowed, in band registration for v1.0 was
decided by the Sept. F2F to be included
 (#58) Should only POEs be published, only service or both
     - Remove UDDI definitions from spec, focus initial efforts on the
information model that should be published to a directory for a Producer.
 (#59) Interface discovery
     - Sept F2F retained wsdl field. If information was gathered prior to
calling
getServiceDescription() [ by using out of band mechanisms], it can be
ignored.
 (#60) Presentation on WS-Security
     - A presentation did in fact occur in the September F2F
 (#61) Interface Factoring
     - Sept. F2F decided to factor the interface using 4 factors. V0.7
reflects this factoring
 (#62) Entity Management
     - Process outlined in v0.7 based on September F2F decisions
 (#64) Preference management negotiation
     - All permutations were approved at Sept F2F. Persistent state only
produced by entity. In the case of Consumer UI gathering property updates,
the setEntityProperties() sets the entity's state regardless of where it is
stored.
 (#65) JSR synchronization - request for presentation
     - A presentation was in fact…presented at the September F2F
 (#68) Do we need initenvironment ?
     - Yes. It is needed.
 (#76) Why is the fact that Consumer supports transcoding surfaced in the
spec?
     - characterSetConversion removed from meta-data
 (#77) specific semantics of sendPublishedState
     - sendPublishedState removed from meta-data
 (#83) Is markupType a MIME type?
     - markupType MUST be a MIME type
 (#85) sessionID/expires MUST/MAY contradiction
     - Language updated ... Basically MUST with a couple of exceptions.
 (#87) Modes as navigation state vs. Modes as another state of the Entity
     - It was decided in the September F2F that Mode is a piece of state
related to the Consumer's viewer, not the entity's state
 (#95) destroyEntities() & refHandles
     - Draft v0.7 does not allow refHandles to be passed to
destroyEntities() as the semantics are to destroy the persistent entity,
not a runtime refinement of it.
 (#103) In vendor extensibility "object any" should be an array
     - Captured in v0.8 ... actually change for interoperability reasons
was to "Extension[] extensions where an Extension object just contains an
<any/>

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

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

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

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 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".

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

9.  (#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? Follow-on the discussion of
ValidationKeys vs InvalidationKeys.