Re: [sca-bindings] Issue 25 inlined proposal

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Simon Nash wrote:
> 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.

Not really part of this issue, but good to fix it (as I have fixed it 
for another reference).
Done.

> 
> 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.
> 

Done.

> 3. Line 117: non-RFC2119 "optional".  This can be removed.
> 

Done.

> 4. Line 172 (SOAP 1.2 paragraph): Change wsoap11 to wsoap12.
> 

Done.

All these changes will be reflected in the next version of the proposal.

-Anish
--

>   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
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> 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