[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues for next several calls
Sorry for the delay in getting this out ... I had a hard drive failure after our call on Thursday and am just coming back online with a new one. Expect updates to this schedule based on the progress we make in the calls (and any new issues) ..... Of the issues currently open, I propose we address them with this schedule: Call on 12/19: #186: Specify the "SHOULD tokens" for the defaultTemplate #171: Expand "Typical Process Flow" and remove "Example scenarios" #172: Remove section "Interaction Lifecycle states" #173: Add summary of interfaces in beginning of interface chapters => I think a summary chapter between 3 (last intro section) and 4 (first interface section) could work well #179: requestParameter semantics unclear (Does resolution impact tentative resolution of #165? => Consumer must strip the prefix it supplied for namespacing) #177: locale MAY be based on end-user settings and not SHOULD #180: <base> tag should be "other tags" and not to "disallowed" tag #184: Can performInteraction return new navigationalState? #178: The Consumer SHOULD NOT use a MODE not specified in meta- data #176: Simplify Producer by allowing it to return all locales re gardless of "desiredLocales" #187: How does POST data reach the Producer? #170: Scope of Producer-Consumer HTTP session Call on 1/2: #185: Remove concept of Roles from the spec #174: The Consumer SHOULD NOT assert a role for a role which th e Producer does not have => proposal: add verbiage to the effect that the Consumer MUST NOT assert a role the Producer has not said it supports. The Producer SHOULD be prepared to receive a role it does not currently support as it may have existed in a previous service description. The Consumer is not required to get a current snapshot all the time, but must abide by the snapshot it has. #175: Roles should be per-Entity and not per-Producer #181: registration changes - proposal is: Drop the registration API so that registration is always out of band and do not pass any additional data. Whatever the Producer actually needs can be acquired/modified through its out-of-band system. Call on 1/7: #169: Does refresh page (F5/Ctrl+R) re-invoke performBlockingInteraction? #183: markup charset different or the same as the XML response charset? Call on 1/9: #182: Globalize the Address Type/User Information fields and Postal Code is missing. => This is delayed to here because I am trying to pull together a table comparing the internalization specs and what we now have Rich Thompson
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC