Re: [sca-bindings] Issue 25 inlined proposal

[Eric Johnson <eric@tibco.com>]

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.