sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Issue 2 proposal v12
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Mon, 6 Apr 2009 11:01:07 +0100
Folks,
Comment inline
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Simon Nash <oasis@cjnash.com>
|
To:
| sca-bindings@lists.oasis-open.org
|
Date:
| 03/04/2009 15:05
|
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.
>
> 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'.
>
"At the same time" seems to be logically (or logistically) impossible.
With most computers, one action occurs either before or after
another action. If actions truly do occur at the same time, it
would be by amazing coincidence rather than deliberate intention.
Simon
<mje>
I'm struggling to see why we are making such
a meal of this. I think I said it clearly on
the last call that the requirement is:
The callback endpoint must be in existence
no later than the point where
the client application code has invoked a
forward operation on the reference and before
the binding code transmits this invocation
on the wire to the service.
The distinction between the application code
and the binding implementation puts
the responsibility cleanly onto the binding
implementation code.
</mje>
> 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
>
>
>
---------------------------------------------------------------------
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]