Re: [sca-bindings] Proposal 01 for Issue 54

[Simon Nash <oasis@cjnash.com>]

Eric,
Here are my comments on proposal 02:

1. The order of the steps in section 2.1 should be a MUST.
    How the resulting URI relates to the runtime endpoint should
    be a SHOULD.

2. (editorial) change sub-items under point 1 for service to
    bullets, as they are not order-dependent.

3. Do we need "absolute URI" in point 2 for service?  The corresponding
    wording for reference just says "URI".

4. (editorial) change sub-items under point 3 for service to
    top-level items, to align with the corresponding items in
    the reference section.

5. In sub-point 1 of point 3 for service, what happens if all the
    port elements are not consistent with runtime policies and
    constraints?  I think this SHOULD (or MUST) cause an error
    to be raised.

6. In sub-point 2 of point 3 for service, what happens if the
    port element is not consistent with runtime policies and
    constraints?  I think this SHOULD (or MUST) cause an error
    to be raised.

7. Split point 5 for reference into two points: one if the reference
    is wired, and another if it isn't (Mike's "intent" case).

   Simon

Eric Johnson wrote:
> Hi Anish,
> 
> Anish Karmarkar wrote:
>> 1) In section 3.1, bullet 3.1 (for service) says:
>> "... and references a wsdl:service element, then use the URI indicated 
>> by each contained wsdl:port element"
>>
>> In section 3.1, bullet 3 (for reference) says:
>> "If the @wsdlElement attribute is present and references a 
>> wsdl:service element, use the URI indicated by any contained wsdl:port 
>> element that satisfies runtime policies and constraints"
>>
>> Any particular reason runtime policy and constraints are important for 
>> reference but not for service?
>>
>> We also say in the explanation of @wsdlElement that only those ports 
>> in the WSDL service element that have equivalent portType are made 
>> available.
> I updated the wording on the (for service) section.
>>
>> 2) We don't require that when endpointReference and @wsdlElement are 
>> both used the wsdlElement MUST reference only a WSDL binding. If this 
>> is true when @URI is specified, it should be true for 
>> endpointReference as well. Both are a way to specify uris.
> We do have precisely the constraint you state here that we don't have: 
> "When this element is present along with the @wsdlElement attribute on 
> the parent element, the @wsdlElement attribute value MUST be of the 
> ‘Binding’ form as specified above"
>> As a side, an EPR can contain WSDL metadata. What happens if the EPR 
>> points to a WSDL binding in its metadata section. Can it be different 
>> from the one pointed to by @wsdlElement? I would like to suggest that 
>> it be a "compatible super/subset".
> Wow.  The insanity.  How about we leave it undefined?
>>
>> 3) For reference (in bullet 5) it says:
>> "Otherwise, the URI for the reference is determined by the binding it 
>> is wired to, or by deployment"
>> Isn't it always determined by the binding it is wired to?
> Is it an error if you have <binding.ws /> but no target specified?  If 
> you haven't specified a target, then you can wire this at deployment.
>>
>> 4) A very minor editorial comment. It would nice if the algorithms for 
>> service and ref were structured (wrt bullets) similarly.
> I'm not sure what you mean by this.  Perhaps we can discuss during the 
> call.  At a guess, I moved the last "otherwise" into a fifth bullet point.
> 
> Revised version attached.
> 
> 
>>
>> -Anish
>> -- 
>>
>> Eric Johnson wrote:
>>> Attached as revisions to CD02.
>>>
>>> I did my best to capture many of the points raised in the calls in which
>>> we talked about this, but I suspect I missed something.
>>>
>>> If you review before next call, and have comments, I'll do my best to
>>> integrate those comments before then.
>>>
>>> Please excuse the fact that OpenOffice completely mangled the table of
>>> contents.  If you don't update the TOC before saving, it sometimes gets
>>> confused.  No changes intended there.
>>>
>>> -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