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] Updated proposal for BINDINGS-54 - proposal rev#8


Eric Johnson wrote:
> OK, one more try.
> 
> Simon Nash wrote:
>> Eric,
>> Thanks for doing this.  I think we are getting close now.
>> Here are my comments on this draft.
>>
>> 1. The new normative rule added to the description of the @uri
>>    attribute would be better placed at the end of section 2, as
>>    it covers not only the @uri attribute but also the @wsdlElement
>>    attribute and the endpointReference element.  Also, the words
>>    "@wsdlElement attribute referring to a WSDL port" should be
>>    changed to "@wsdlElement attribute referring to a WSDL Port
>>    or WSDL Service".
> Agreed.  Except that the WSDL specification does not capitalize either
> "port" or "service", so I've left these lower case.
>> 2. I'm fine with the intention of the two new paragraphs covering
>>    service URIs, but some of the wording in the first paragraph
>>    doesn't feel quite right.  For example, it doesn't seem right to
>>    say "Unfortunately" as there could be excellent reasons for not
>>    using the exact URI specified.  Also, it's suggested that an
>>    alternate URI would only be used if it's impossible to honor the
>>    specified URI, but there could be cases where it's legitimate to
>>    use a different URI even though the specified URI could have been
>>    used.  Also, the reference to an "end user's possible surprise"
>>    doesn't seem quite right in a spec document, and I'm not sure what
>>    "flagging the differences" means.  Here's my attempt to reword
>>    this paragraph:
>>
>>    This specification does not mandate any particular way to determine
>>    the URI for a web services binding on an SCA service.  An absolute
>>    URI can be indicated by the @uri attribute, by the URI in a
>> wsa:Address
>>    element within an endpointReference element, or by the URI indicated
>>    in a WSDL Port via a @wsdlElement attribute.  Implementations can
>>    use the specified URI as the service endpoint URI or they can use a
>>    different URI which might include portions of the specified URI.
>>    For example, the service endpoint URI might be produced by modifying
>>    the specified URI to use a different host name or port number.
> I like my text.  Shall we let the TC decide?
>> 3. Under point 1 in the algorithm for reference URIs, the second
>>    sentence is redundant (assuming the change in item 1 above)
>>    and should be removed.
> Agreed.  The change I made here was to remove the RFC 2119 language.  I
> thought it useful to remind the reader.  I've left this as is in my
> latest revision.
 >
I think the third bullet makes this extrememly clear.  Having the
same information twice in the same list seems more confusing to me.

>> 4. With the new prohibition on using any combinations of @uri,
>>    endpointReference, @wsdlElement/wsdl.port and
>> @wsdlElement/wsdl.service,
>>    points 1, 2 and 3 of the algorithm for reference URIs are now
>>    mutually exclusive.  This means we no longer need to use an
>>    algorithm with ordered steps.
> I thought about this, and almost changed it with the 07 draft.  Since
> you noticed this as well, I've now changed it.
 >
I don't think we still need the reference to "first step"
before the bullets.  It's also no longer appropriate to refer to
"above steps" after the bullet.  We should be able to collapse the
text before and after the bullet into a single normative rule, as
follows:

  For a reference binding, the SCA runtime MUST apply the appropriate
  rule from the following, or raise an error:

  <the bullets follow>

   Simon

>> 5. In the wsdl:service sub-bullet of the wsdlElement bullet, change
>>    "as specified as under" to "as specified under".
> Another entry in my embarrassing litany of typos.  Thanks.
> 
> -Eric.
>>   Simon
>>
>> Eric Johnson wrote:
>>> Updated proposal for bindings 54.
>>>
>>> Changes:
>>>
>>>     * Added new conformance statement at the definition of @uri
>>>     * Removed proposed conformance statement from the definition of
>>>       endpointReference (moved to @uri)
>>>     * Section 2.2 - two new paragraphs talking about the treatment of
>>>       URIs for bindings on a service.
>>>     * (Simon N) - Fixed establishs --> establishes typo
>>>     * (Simon N) - Change "as defined as under the definition" to "as
>>>       specified under the definition".
>>>     * (Simon N) - Change "by port element" to "by the port element"
>>>     * (Simon N) - Removed "In both of the above cases, the SCA runtime
>>>       MUST raise an error if there is not at least one port compatible
>>>       with runtime policies and constraints". This assumes that
>>>       resolution to BINDINGS-23 passes.
>>>     * Under 2.2, list item #1, replaced sentence - "The @wsdlElement
>>>       attribute, if present MUST NOT reference anything other than a
>>>       wsdl:binding element" with "The @wsdlElement attribute, if
>>>       present, cannot reference anything other than a wsdl:binding
>>>       element", as the normative statement is redundant with conformance
>>>       statement under @uri.
>>>     * (Simon N) - list item #3, removed sentence - "In both of the above
>>>       cases, the SCA runtime MUST raise an error if there is not at
>>>       least one port compatible with runtime policies and constraints."
>>>       - as this is presumed to be redundant subsequent to resolution of
>>>       BINDINGS-23
>>>     * (Simon N) - Change "reference a URIs" to "a reference URI"
>>>     * (Simon N) - Changed the conformance statement at the very end of
>>>       section 2.2 to be a "MUST", not a "SHOULD".
>>>
>>> This completes my action item 20090507-2
>>>
>>> Special thanks to Simon Nash for catching all the typos in my
>>> previous revision.
>>>
>>> -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 
>>




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