[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 25 inlined proposal
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]. 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. 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? > 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. 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. -Eric.