[wsrp-wsia] Issues Resolved (19-Dec-2002)

[Gil Tayar <Gil.Tayar@webcollage.com>]

Issue: 171
Status: Resolved
Topic: introduction
Class: Editorial
Raised by: Eilon Reshef
Title: Expand "Typical Process Flow" and remove "Example scenarios"
Date Added: 10-Dec-2002
Document Section:   v0.85/1.3&1.4
Description:
The different scenarios should belong in the primer
Resolution:
Remove the example scenario and point to the primer

 

Issue: 172
Status: Resolved
Topic: introduction
Class: Editorial
Raised by: Eilon Reshef
Title: Remove section "Interaction Lifecycle states"
Date Added: 10-Dec-2002
Document Section:   v0.85/3.12
Description:
This section is non-normative. I believe it is an archeological artifact of very old discussions in the beginning of WSRP. It also covers very little of the lifecycle, and confuses more than helps.
Resolution:
Remove it

 

Issue: 173
Status: Resolved
Topic: interface
Class: Editorial
Raised by: Eilon Reshef
Title: Add summary of interfaces in beginning of interface chapters
Date Added: 10-Dec-2002
Document Section:   v0.85/4.*, 5., 6.*, 7.*
Description:
Can we add a summary of the signatures of the operaion at the beginning of each of the sections (maybe javadoc-like?)
Resolution:
Add a summary chapter before all interface chapters

 

Issue: 174
Status: Resolved
Topic: interface
Class: Minor Technical
Raised by: Eilon Reshef
Title: The Consumer SHOULD NOT assert a role for a role which the Producer does not have
Date Added: 10-Dec-2002
Document Section:   v0.85/4.1.6
Description:
"The Consumer ""MUST NOT"" assert a role for which no RoleDescription was part of the Producer's ServiceDescription. This should be a ""SHOULD NOT"" because changes to the service description can happen arbitrarily and we can't require Consumers to validate that the service description hasn't changed before each operation invocation.
alternative would be to 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."
Resolution:
Use the alternative

 

Issue: 176
Status: Resolved
Topic: interface
Class: Minor Technical
Raised by: Eilon Reshef       
Title: Simplify Producer by allowing it to return all locales regardless of "desiredLocales"
Date Added: 10-Dec-2002
Document Section:   v0.85/4.2
Description:
getServiceDescription: the current text says that the Producer "MUST use the desiredLocales" to control what locales are returned. This should probably be a "SHOULD" to allow the Producer to return all the locales even if the Consumer requested only some. This will make simplify producer's job of returning information.
Resolution:
As defined - change MUST to SHOULD. Add text about network impact.

 

Issue: 177
Status: Resolved
Topic: interface
Class: Minor Technical
Raised by: Eilon Reshef       
Title: locale MAY be based on end-user settings and not SHOULD
Date Added: 10-Dec-2002
Document Section:   v0.85/5.1.6
Description:
Current text suggests that Consumers "SHOULD" supply locale information based on the setting of the End-User. I suggest to replace it with "MAY". The Consumer may also decide to supply this information based on the IP address of the user, based on corporate policy, etc. This is an application-level decision.
Resolution:
Accepted - MAY instead of SHOULD

 

Issue: 178

Status: Resolved
Topic: interface
Class: Minor Technical
Raised by: Eilon Reshef       
Title: The Consumer SHOULD NOT use a MODE not specified in meta-data
Date Added: 10-Dec-2002
Document Section:   v0.85/5.1.6
Description:
"Current text suggests that the Consumer MUST specify one of the modes from the entity meta-data. This should probably change into ""SHOULD"" because the service description may always change unexpectedly (Spec 0.85 Page 35 - line 18).
alternative would be to add verbiage to the effect that the Consumer MUST NOT use a mode that the entity has not said it supports. The Producer SHOULD be prepared to receive a mode 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.
See #174 for same problem with roles"
Resolution:
Use the alternative

 

Issue: 180
Status: Resolved
Topic: markup
Class: Minor Technical
Raised by: Eilon Reshef       
Title: <base> tag should be "other tags" and not to "disallowed" tag
Date Added: 10-Dec-2002
Document Section:   v0.85/9.4.1.1
Description:
The "base" tag is currently defined as disallowed. It should be moved to the "other tags", as one can (using JavaScript) put a <base> around a certain area and return the <base> to what it was before - without affecting the Consumer - it's very similar to the other "bad" tags such as <link> etc. that need to be used with care
Resolution:
Move <base> to "other" tags

 

Issue: 186
Status: Resolved
Topic: markup
Class: Minor Technical
Raised by: Eric VanLydegraf   
Title:     Specify the "SHOULD tokens" for the defaultTemplate
Date Added: 15-Dec-2002
Document Section:   v0.85/9.2.2.9/10
Description:
9.2.2.3 gives a list of tokens that SHOULD be in the template blockingActionTemplate. Because defaultTemplate serves as a default for this template, the same list should be in the section on defaultTemplate. Same for secureDefaultTemplate
Resolution:
Do it

Gil Tayar

WebCollage