Re: [sca-bindings] Issue 2 proposal v12

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Thanks Dave.
I will send a new version (v13) shortly after incorporating your and 
SimonN's changes.

Responses to your word comments:

1) DAB: These sentences just don’t read correctly, can we start them 
with ‘If’ ?

I have made that (added 'if') change.
I think the whole paragraph can be made better (we can use if-then-else 
and remove a 'MUST'), but at this stage I would rather not make any changes.

2) DAB: Should we update this to match the current namespace?

This comment is for the wsa:RelatesTo/@RelationshipType attribute value 
URI. This URI value has nothing to do with our NS URI, in principle. We 
*could* make it the same as our NS URI. It would be easier to remember 
just one. But I don't think we should change it in the future if the NS 
URI changes but the semantics of the protocol don't (or vice versa). 
This may lead to some confusion (if people expect them to be in sync), 
if the NS URI changes in the future. Furthermore, I would rather see a 
URI that is completely under the control of this TC rather than the 
assembly TC. Overall I tend to lean towards saying that we should keep 
this URI independent of our NS.

3) DAB: How can ‘right after’ ever work?

You're correct, this is a problem. It is important for the listener case 
that the listener be ready before or at the same time the forward 
request is made. In the listener case, a connection failure may be 
treated by the service as fatal. For the polling case 'right after' is 
ok. I have changed the words for the listener case to say: 'before or at 
the same time'.

4) DAB: We should move to the 200903 schema level that assembly is on.

This refers to the NS for the policy assertion.
In most, though not all, I expect this assertion to be used independent 
of the composite file (in WSDLs/external attachments). I don't have a 
strong opinion on this, but a mild preference to keep it independent of 
the main assembly NS. I see the use of this assertion on the edges of 
the domain and for interoperability across vendors/clients. Having the 
ability to evolve this without the need to rev assembly NS (or vice 
versa) would be good.

-Anish
--

David Booz wrote:
> Comments in this document. Turn off all reviewers but me to see all the 
> changes, some are editorial where I changed the text directly instead of 
> making Word comments.
> 
> /(See attached file: SCA-bindings-issue2-proposal-v12_dab.doc)/
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> Inactive hide details for Anish Karmarkar ---04/02/2009 02:01:10 
> AM---Attached. I believe I included all the changes agreed to Anish 
> Karmarkar ---04/02/2009 02:01:10 AM---Attached. I believe I included all 
> the changes agreed to from last week.
> 
> 
> From:	
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 
> To:	
> OASIS Bindings <sca-bindings@lists.oasis-open.org>
> 
> Date:	
> 04/02/2009 02:01 AM
> 
> Subject:	
> [sca-bindings] Issue 2 proposal v12
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Attached.
> I believe I included all the changes agreed to from last week.
> 
> The only quibble that I have with the wordings is that it talks about
> 'binding on the reference-side'. Since this is expected to be used at
> the edges of the domain, it is preferable to not talk about 'references'
> but instead say something like 'binding on the client-side' or 'the
> invoker's binding'.
> 
> -Anish
> --
> [attachment "SCA-bindings-issue2-proposal-v12.doc" deleted by David 
> Booz/Poughkeepsie/IBM] 
> ---------------------------------------------------------------------
> 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