Unaddressed LC comments

In order to helps us make further progress before the summer vacation, 
I've looked at each of the unaddressed LC comments and made suggestions 
below. I believe we can dispose of most comments fairly easily.

I hope you will find this useful,

JJ.

PS. I'm sorry for posting this only today; and I will be unavailable 
next Thursday.

Jonathan Marsh wrote:

>6.  Unaddressed LC comments:
>  - LC5a: QA Review on WSDL 2.0 Part 1, intro and conformance issues 
>          (a) [.1]
>          Objection [.2]  Jonathan to provide more detail.
>  
>
They were 3 subissues in the original comment [.1]:
 a) Do the expressions "processor MUST fault" and "processor MUST fail" 
mean the same thing?
 b) "Fault" has a very different meaning elsewhere in WSDL (e.g. fault 
rule).
 c) It "would be beneficial to develop the notion of error handling for 
a WSDL processor".

The reviewer objected (somewhat) to our resolution on 12 May.

On 13 May, Arthur removed any remnant occurrences of "WSDL processor".

So a) (and hence b) is now moot.

c) is only indicative (and not an erea we wanted to address), so we can 
safely ignore it.

>  - LC5f: QA Review on WSDL 2.0 Part 1, intro and conformance issues 
>          (f) [.3]
>          Objection [.2]  Suggest we uphold our current design on the 
>          first point (wants classes of conformant processors), second 
>          point has been fixed - need to notify commenter.
>  
>
I agree with both points above.

>  - LC9:  How does the Operation Name Mapping Requirement [.4]
>          Believe we've satisfied the objection.  See latest mail [.15]
>  
>
I agree. No response from reviewer so far -but the deadline is Wednesday 
next week (12 July).

>  - LC51: Editorial last call review comments [.5]
>          Objection [.6] Asked for more details [.16]
>  
>
Jacek has promised resubmitting the comments he felt had not been 
addressed. He hasn't do so yet.

>  - LC73: Raising an ugly issue again [.7]
>          Objection [.8]  Single interface per service, we've gone over 
>          this before, suggest not attempting to satisfy the comment.
>  
>
I agree. Anyway, the primer has an entire section on the topic [.a].

BTW, ref. [.8] above is wrong.

[.a] 
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.xml#adv-multiple-docs-describing-same-service>

>  - LC75f: Allow extension attributes on RPC local element children [.9]
>           Objection [.10]  Jonathan is looking into this.
>  
>
Probably now moot. I was unable to find the sentence: "The complex type 
that defines the body of an input or an output element MUST NOT contain 
any attributes".

>  - LC75v: Remove "Processor Conformance" [.11]
>           Objection [.10]  Fixed, but commentor needs to be notified.
>  
>
I agree, this was indeed fixed.

>  - LC76a: MEPs should support addressing mechanism [.12]
>           Objection [.10]  My notes say that Roberto is looking into
>this?
>  
>
I agree with the reviewer the difference in prose between (now) 2.2.1 
and 2.2.2 makes it difficult to grasp the differences. To address this 
objection, as suggest the following rewrite of 2.2.2, which now makes 
the difference explicit (I consider this change as editorial only):

<proposed section="2.2.2">
Any message, including the first in the pattern, MAY trigger a fault 
message, which MUST have opposite direction. The fault message MUST be 
delivered to the originator of the triggering message, unless otherwise 
specified by an extension of binding extension. Any node MAY propagate a 
fault message, and MUST not do so at most once for each triggering 
message. If there is no path to the originator, the fault MUST be discarded.
</proposed>

FYI, here's the current text for 2.2.1 and 2.2.2:

<current section="2.2.1">
Any message after the first in the pattern MAY be replaced with a fault 
message, which MUST have identical direction. The fault message MUST be 
delivered to the same target node as the message it replaces, unless 
otherwise specified by an extension or binding extension. If there is no 
path to this node, the fault MUST be discarded.
</current>

<current section="2.2.1">
Any message, including the first, MAY trigger a fault message in 
response. Each recipient MAY propagate a fault message, and MUST 
propagate no more than one fault for each triggering message. Each fault 
message has direction the reverse of its triggering message. The fault 
message MUST be delivered to the originator of the message which 
triggered it, unless otherwise specified by an extension or binding 
extension. If there is no path to this node, the fault MUST be discarded.
</current>

I'll send the above proposal in a separate email, for easier 
referenceability.

>  - LC76c: WSDL 2.0 LC Comments (Part 2) (c) [.13]
>           Objection [.10]  Proposal [.17]
>  
>
I agree with Jonathan's proposal [.17]. From his proposal, I'll only 
delete the word "security", as there may be other contigences which 
prevent the delivery of the fault, e.g. proxies, unreliable transmission.

>  - LC76d: Replace ADD with header construct [.14]
>           Objection [.10]  Needs discussion.
>  
>
Moot. We now support SOAP headers [.b].

[.b] 
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#soap-headers-decl>

>  - LC91: XML Schema comment "T2" on WSDL 2.0 [.18]
>          Objection? and proposal [.19]
>  
>
Noah's proposal to his objection looks good as is.

>  - LC96: wsdl:import semantics is different from xs:import [.20]
>          Objection? and proposal [.21]
>  
>
Noahs's proposal looks good, but the offending text is no longer present.

I hope this helps,

JJ.

>[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5a
>[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5f
>[.3]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0020
>.html
>[.4] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC9
>[.5] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC51
>[.6]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0021
>.html
>[.7] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC73
>[.8]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0020
>.html
>[.9] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75f
>[.10]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0091
>.html
>[.11] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75v
>[.12] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76a
>[.13] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76c
>[.14] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d
>[.15]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0029
>.html
>[.16]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0030
>.html
>[.17] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0093.html
>[.18] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC91
>[.19]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0003
>.html
>[.20] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC96
>[.21]
>http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jun/0004
>.html
>  
>

Received on Thursday, 7 July 2005 09:57:28 UTC