[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 2 proposal v12
David Booz wrote: > Thanks Anish, > > I agree that the URI (and the assertion NS) are independent, and in no > way did I intend to mean that either of them be kept in sync with future > assembly namespace URI changes. It clear that they have independent > lifecycles from Assembly NS and from each other. It was purely a > suggestion and I'm fine either way. For someone with an organized mind > like myself, it looks odd to start out with different URIs, but maybe > that's just me. Looking at the most common relationship URI, it is: http://www.w3.org/2005/08/addressing/reply and the WS-A NS is http://www.w3.org/2005/08/addressing we could follow the same pattern. Since the relationship URI is not a NS, OASIS' NS URI guidlines don't apply. So something like http://docs.oasis-open.org/ns/opencsa/sca/200903/wscallback I don't have a strong preference either way, although the 'ns' in the URI does bother me (so a mild preference for keep the existing one). -Anish -- > > 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 07:11:01 > PM---Thanks Dave. I will send a new version (v13) shortly afteAnish > Karmarkar ---04/02/2009 07:11:01 PM---Thanks Dave. I will send a new > version (v13) shortly after incorporating your and > > > From: > Anish Karmarkar <Anish.Karmarkar@oracle.com> > > To: > sca-bindings@lists.oasis-open.org > > Date: > 04/02/2009 07:11 PM > > Subject: > Re: [sca-bindings] Issue 2 proposal v12 > > ------------------------------------------------------------------------ > > > > 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 > > --------------------------------------------------------------------- > 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]