Re: Suggestion Summary appendix? - CR001

Lawrence,

I've implemented the resolution to your comment which is being tracked as 
CR001.[1]

The resolution is to include optional requirements in the assertion 
summary. These optional assertions correspond to SHOULD, etc. and are 
tagged by adding the attribute required="false" to the <assert> tag. I've 
tagged the ones you identified below and assigned them ids as follows:

description-S0001 -> Description-1201001
interface-fault-S0002 -> InterfaceFault-1203001
interface-operation-S0003 -> InterfaceOperation-1204005
feature-ref-S0004 -> Feature-1207001
property-ref-S0005 -> Property-1208001

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR001

----------------------------------------------

The WSDL 2.0 spec contains many suggestions. I'd like to propose that an 
appendix that captures the suggestions be created. This appendix will be 
similar to appendix E: assertion summary currently being created for the 
assertions. I'll propose the name "Suggestion Summary".

This appendix may be useful to WSDL 2.0 parsers that wish to include the 
suggestions outlined in the WSDL 2.0 spec on validation reports for WSDL 
2.0 instance documents. I see the suggestions being displayed as warnings 
on validation reports.

I've included below five sample suggestions from the WSDL 2.0 spec. For 
each entry I've listed a suggested id (I've used the same structure as for 

the assertions but prefixed the assertion number with the letter S), the 
suggestion, and the location of the suggestion in the spec.: 

description-S0001 
Section 2.1.2
The value of the targetNamespace attribute information item SHOULD be a 
dereferenceable IRI (see [IETF RFC 3987])

interface-fault-S0002 
Section 2.3.1
For the above reason, it is considered good practice to ensure, where 
necessary, that the local name of the {name} property of Interface Fault 
components within a namespace are unique, thus allowing such derivation to 

occur without inadvertent error.

interface-operation-S0003 
Section 2.4.1
For the above reason, it is considered good practice to ensure, where 
necessary, that the {name} property of Interface Operation components 
within a namespace are unique, thus allowing such derivation to occur 
without inadvertent error.

feature-ref-S0004
Section 2.7.1
This IRI SHOULD be dereferenceable to a document that directly or 
indirectly defines the meaning and use of the Feature that it identifies.

property-ref-S0005 
Section 2.8.1
This IRI SHOULD be dereferenceable to a document that directly or 
indirectly defines the meaning and use of the Property that it identifies.




Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca