[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues agenda for 10/17
We talked about this amongst the editors as well. Notice that at the end of
the line for #1 it says "for information only". We have a process in place
that these will move to resolved unless they are objected to ... the
editors would like to view this as a reminder of that transition for those
who want to object on the email list rather than as items to discuss on the
call. The actual discussion items start at #2 (Issue #26).
Michael Freedman
<Michael.Freedman@ To: wsrp-wsia@lists.oasis-open.org
oracle.com> cc:
Subject: Re: [wsrp-wsia] Issues agenda for 10/17
10/15/2002 01:53
PM
Rich,
I wonder if we can make our Thursday calls more efficient if we don't
cover
Item #1: moving tentative resolved to resolved on a line by line basis?
Instead could we just ask the group if there are any items that should be
discussed/deferred prior to adopting the lot? And then proceed to accept
the
rest as a group without explanation? This might allow us to move into the
more
substantive issues earlier in the call.
-Mike-
Rich Thompson wrote:
> 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?
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC