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

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