Re: [sca-bindings] Re: Proposed resolution to issue 54, attempt #6

[Simon Nash <oasis@cjnash.com>]

Eric,
Here are my comments on the proposed text for reference URIs:

1. Lines 288-290 should not be indented.

2. Line 290: Typo "establishs" for "establishes".

3. Line 300: Change "as defined as under the definition" to "as
    specified under the definition".

4. Line 302: Change "by port element" to "by the port element".

5. Lines 303-304 seem to be redundant given the proposed resolution
    to BINDINGS-23.

6. Line 306: Change "reference a URIs" to "a reference URI".

6. On line 306, why is this a SHOULD (for a reference)?  I think
    it should be a MUST.

   Simon

Eric Johnson wrote:
> Based on my comments below, I've written up another proposal.  This time 
> around, I'm just punting on determining a URI for a service.
> 
> -Eric.
> 
> Eric Johnson wrote:
>> Mike raises a question which I don't know how to resolve:
>>
>> Mike Edwards wrote:
>>
>> [snip]
>>>
>>> 1) Lines 308 - 310 now say:
>>>
>>> "In some cases the URI determined by previous steps is relative to 
>>> the structural URI for either an SCA service or binding.  In case of 
>>> such a URI, the runtime SHOULD combine the relative URI with an 
>>> absolute deployment target URI."
>>>
>> [snip]
>>>
>>> b) it introduces the concept "absolute deployment target URI" - where 
>>> is this defined and described?  As a whole, it seems very vague.
>>>
>> I really don't know what to suggest here, in that I agree that it is 
>> vague.  I had thought that Assembly had some tighter language around 
>> some notion of a deployment URI, but after just reviewing, I don't see it.
>>
>> I'm left with a few options, and the last one I felt like I should 
>> add, just because specifying a URI for a service at the time you're 
>> composing a composite is rife with issues.
>>
>> Options:
>>
>>     * Attempt to define what a deployment target URI would be.
>>     * Vaguely state that the structural URI should be used in
>>       constructing the actual deployment URI.
>>     * Leave it completely to the implementation to decide what to do
>>       with a URI, relative or absolute
>>     * Forgo any attempt to specify how a URI is determined for a service.
>>
>> My attempts at issue 54 have so far have attempted (mostly) to keep 
>> what I perceived as the original intent, which allowed for specifying 
>> the URI of a service as part of the design-time configuration.  
>> However, recognizing that a URI known when constructing a composite 
>> may have no relationship to an actual deployed environment, it is 
>> extremely difficult to say how to honor that URI.  For example, if the 
>> URI indicates "http", but there's a policy intent that effectively 
>> dictates HTTPS, what do we do?  Is our spec:
>>
>>     * Treating this as an error?
>>     * Encouraging implementations to alert users to the discrepancy?
>>     * Mum on the point?
>>
>> I note, in contrast to what we're currently doing with binding.ws, 
>> that section 8.4 of the assembly spec, when discussing binding.sca, 
>> says "If the binding @uri attribute is specified on a service, it is 
>> ignored."
>>
>> I'm almost ready to throw in the towel, because I don't see that we 
>> can tightly define this in a sensible way.  For services, I'd suggest 
>> adding text on the order of this:
>>
>> In determining the URI for a service, implementations are encouraged 
>> to attempt to honor the value(s) of @uri attribute, the URI in a 
>> wsa:Address element from an endpointReference, the URI indicated by 
>> WSDL port via a @wsdlElement attribute references, and the structural 
>> URI for the binding.
>>
>> Comments?
>>
>> -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