Here are my comments on the proposal. Line numbers are
taken from the doc, so they may not be an exact match for
what others are seeing.
1. Line 31: The [SCA-JCAA] reference should be .pdf, not .html.
2. Line 115: non-RFC2119 "optional". This can be removed.
Also reorder the sentence as follows:
The SCA runtime MUST support all the attributes of the
<binding.ws> element, namely @name, @uri, @requires,
@policySets, @wsdlElement, and @wsdli:wsdlLocation.
3. Line 117: non-RFC2119 "optional". This can be removed.
4. Line 172 (SOAP 1.2 paragraph): Change wsoap11 to wsoap12.
Simon
Anish Karmarkar wrote:
> Comments inlined below.
>
> -Anish
> --
>
> Eric Johnson wrote:
>> Hi Anish,
>>
>> Thank you very much for putting the proposed changes into the document.
>>
>> Anish Karmarkar wrote:
>>> Per today's concall discussion, I have created a proposal for issue 25
>>> using CD02 as the basis.
>>>
>>> Specifically:
>>> 1) I left points 1, 2 from the previous proposal and 2.1 from the chat
>>> in section 5.
>> On this point, I believe we're agreed that the forward looking intent of
>> #1 in your update is that we must support the items that are listed in
>> the "mandatory" section of the new appendix, and once the "optional"
>> proposal for issue 2 is adopted, we'll have to alter this statement so
>> that it matches our intent.
>>
>> The repetition dismays me somewhat. I'd rather that we say something
>> like:
>>
>> The implementation MUST conform to the SCA Assembly Model Specification
>> Version 1.1 [SCA-Assembly], and to the SCA Policy Framework Version 1.1
>> [SCA-Policy].
>
> Fine with me.
> Don't particularly care either way; the wordings in the proposal were
> selected to keep things similar to other SCA specs.
>
>>
>> rather than have two separate bullets.
>>
>>> 2) Moved the requirements regarding optional attributes and elements
>>> to section 2. Note that the original proposal talked only about
>>> @wsdli:wsdlLocation, @wsdlElement, and <endpointReference>, which
>>> seemed like a strange thing to do. So I have made a statement about
>>> all the the optional attributes and children elements.
>> Since the @name, @requires, and @policySets are pass-throughs for what
>> is happening in Assembly and Policy specs, it feels like we're trying to
>> do the work of the assembly spec, and it therefore strikes me as
>> inappropriate.
>
> I'm not sure if that is true. AFAIK, assembly/policy are silent on this.
> The <binding> element defined in Assembly is abstract, it can never
> occur in an XML document. One interpretation can be that it is up to the
> specific binding type to decide on this.
> But if we raise an issue against the assembly I suppose we can leave it
> to the assembly spec to say something about this.
>
>> Stating a normative requirement on @uri duplicates the
>> work of issue 54 to say how URI resolution works. Saying here that it
>> must be supported doesn't seem to add value. Did I miss something?
>
> Issue 54 proposal talks about what should happen if it is supported, but
> not that it must be supported. IOW, a runtime can reject a composite
> that uses the @uri attribute and still claim conformance. Perhaps I
> missed a 'must' in your proposal.
>
>>> 3) Moved the requirement to support wsdl 1.1 bindings for soap 1.1/1.2
>>> over http to section 2.6. The wordings are tweaked along the lines of
>>> what Eric was suggesting. I also replaced the NS with the appropriate
>>> prefix.
>>> 4) The requirements regarding intents are moved to section 2.8.
>>> 5) In addition, I have added three requirements to section 5. These
>>> requirement were not part of the original proposal. They are about
>>> what the runtime must do when it encounters a <binding.ws> element in
>>> a composite, constrainingType or a componentType that does not conform
>>> to the schema. The requirements are very similar to the conformance
>>> requirements specified by the assembly and BPEL conformance section.
>>> If you think these requirements should be in a different section,
>>> please do let me know. I didn't find a suitable section and figured
>>> aligning with assembly and BPEL spec would be a good thing.
>> Repetition as a bludgeon!
>>
>> How about:
>>
>> The SCA runtime MUST reject any SCA Composite Document or SCA Component
>> Type Document, as defined in Section 13 of the SCA Assembly Model
>> Specification 1.1 [SCA-Assembly], if such a document contains the
>> <binding.ws> element that is not valid according to its XML Schema.
>>
>
> Fine with me.
>
>> Note that in the above rewrite, I've removed the reference to
>> constraining type documents, because as I understand it, constraining
>> types do not have bindings, so the question doesn't arise.
>>
>
> That is correct. ConstrainingTypes should not have been part of the
> proposal.
>
>> -Eric.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
