OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-bindings] Issue 25 inlined proposal

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]