[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] Issues agenda for 10/17
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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC