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:
>
> 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 <>
>
> To:
>
>
> 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:
> >
> > 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 <>
> >
> > To:
> > OASIS Bindings <>
> >
> > 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
>
>
>
