Minutes
Opening
<Mike Edwards>
meeting is quorate with 22 of 35 attending
Action Items
MikeE:
would like to review open AI
... Dieter was supposed to raise a issue in BPEL TC
... Dieter confirmed his action as done
Resolution: M:Henning S:Peter Walker Minutes of 2007-12-04 approved w/o
Open Issues
MikeE (as a TC member) presents the issue
MikeE:
The current proposal follows RFC 2119
... describes the five different ways of defining a target service
... The link above for the proposal is wrong
... Link for the right proposal:
... <Sighs and grunts due to difficulty in finding the right proposal on Kavi>
... this proposal describes six different ways of defining a target service
... MikeE describes further rules on combinations and specifics of each mechanism
SimonNash:
Not sure if the use of 'MAY' is compliant with RFC 2119
... intention does not seem to be - implementation optionality
Martin:
One of the binding types must be used
<Martin>
change Where the reference has a value specified in its @target attribute, all the
binding types identified by the child binding elements MAY be used
on each wire created by the @target attribute.
<Martin>
to -
Where the reference has a value specified in its @target attribute, any one of the
binding types identified by the child binding elements MUST be used
on each wire created by the @target attribute.
MichaelR:
It should be possible to override the binding
... if it is both promoted and overridden
... not sure if this case is actually possible
Henning:
There is also the case of no binding is specified where binding.sca is assumed
... Suggests - if bindings are specified then one of the bindings must be used
MikeE:
You can't identify a target attribute and still override it
... ruling out the 'promoted and overridden' case
Scott:
s/any one/some one
Martin:
use of 'any one' is fine
MikeE:
Need to address the case brought up by Henning - no binding is specified
MichaelR:
It is covered by elsewhere as an implicit assumption of binding.sca
... however 'binding types' should be 'bindings'
<Michael Rowley>
Where the reference has a value specified in its @target attribute, one of the
bindings identified by the child binding elements MUST be used
on each wire created by the @target attribute.
<Michael Rowley>
Where the reference has a value specified in its @target attribute, one of the
child binding elements MUST be used
on each wire created by the @target attribute (or the sca binding, if no binding is specified).
MikeE continues to present rest of the proposal ...
Martin:
why are we using English text instead of schema
MikeE:
This text relates multiplicity with reference settings
... nothing in schema covers this
MichaelR:
There is an implication that the six ways of specifying target service can be mixed and matched with the different cases
of multplicities
... not sure how to clarify this though
MikeE:
suggests to proceed with current proposal first
... and deal clarifications seperately
MikeE describes the text related to deployment and error generation
MichaelR:
There are times where error can not be generated until invocation
Martin:
We need to raise a general issue regarding timing of error generation
SimonNash:
Next paragraphs seems to address this
Action: Martin Chapman to raise a generic issue for error generation
<Michael Rowley>
change- Where it is detected the the above rules have been violated, either at deployment
or at execution time, an SCA Runtime MUST generate an error before the reference
is invoked by the component implementation
to- Where it is detected the the above rules have been violated, either at deployment
or at execution time, an SCA Runtime MUST generate an error no later than when the reference
is invoked by the component implementation
<tomRutt>
The actual way errors are raised can be implementation specific (put in log file, send email to an admin, etc.) Many WS-*
specs leave this flexible. Cannot assume fault indication can be sent on a network.
<Michael Rowley>
[Removing the extra "the"] Where it is detected the above rules have been violated, either at deployment
or at execution time, an SCA Runtime MUST generate an error before the reference
is invoked by the component implementation.
TomRutt:
We should leave some degree of flexibility in specifying exact ways of raising an error
<Michael Rowley>
But then I pasted in the wrong version of the sentence :-(.
MartinC:
Where a static analysis is possible, violation rules should be specified
<Michael Rowley>
Where it is detected that the above rules have been violated, either at deployment
or at execution time, an SCA Runtime MUST generate an error no later than when the reference
is invoked by the component implementation.
Next para: Other errors can only be checked at runtime. Examples include cases of
components deployed to the SCA Domain. At the Domain level, the target of
a wire, or even the wire itself, may form part of a separate deployed
contribution and as a result these may be deployed after the original
component is deployed. In these cases, the SCA runtime MUST generate an
error before the reference is invoked by the component implementation.
SimonNash:
We need the same 'no later than' fix for this para too
SimonNash:
We need the same 'no later than' fix for this para too
<Mike Edwards>
In these cases, the SCA runtime MUST generate an
error no later than when the reference is invoked by the component implementation
MartinC:
Section numbering needs to be fixed
MikeE:
Editors could fix this
Where a component reference is promoted by a composite reference, the
promotion MUST be treated from a multiplicity perspective as providing 0 or more
target services for the component reference, depending upon the further
configuration of the composite reference. These target services are in
addition to any target services identified on the component reference itself,
subject to the rules relating to multiplicity described in this section.
MikeE continues with the proposal ...
para: For the binding of a reference, the uri attribute defines the target URI
of the reference. This MAY be either the componentName/serviceName for
a wire to an endpoint within the SCA domain, or the accessible address
of some service endpoint either inside or outside the SCA domain (where
the addressing scheme is defined by the type of the binding).
SimonNash:
s/MAY/MUST as these are the only two options
Henning:
What about the binding that need additional data?
MikeE:
Covered in the previous section
Action: MikeE to send out an updated proposal to the list
Resolution: m:Edwards s:Nash accept the proposal as described and modified above as the resolution to issue Assembly-6
ASSEMBLY-11
MartinC:
I own an action item related to this issue
AoB
Meeting closed a 8:59 AM Pacific Time
Schreiber diagnostics output
[Delete this section before publishing the minutes]
citation-detection-scribed: Line 196: Check for possible unrecognized nick 'Next para'
citation-detection-scribed: Line 225: Check for possible unrecognized nick 'para'
statistics: Schreiber found 166 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 168: Sanjay: s/seem/seems
citation-detection-irc1: Line 14: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 18: Check for possible unrecognized nick 'ASSEMBLY-6'
citation-detection-irc1: Line 19: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 20: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 22: Check for possible unrecognized nick 'ASSEMBLY-11'
citation-detection-irc1: Line 23: Check for possible unrecognized nick 'http'
citation-detection-irc1: Line 27: Check for possible unrecognized nick 'ASSEMBLY-31'
citation-detection-irc1: Line 28: Check for possible unrecognized nick 'http'
command-scribe: Line 64: Sanjay is a nick for Sanjay Patil who will be named as scribe
command-scribe: Schreiber detected that this section was scribed online
citation-detection-irc1: Line 82: Check for possible unrecognized nick 'http'
edit-substitute: command on line 168 succeeded, changed line 166 from 'seem' to 'seems'
edit-delete: Line 168 was deleted
system: Transformer: SAXON SA 8.9
[End of Schreiber diagnostic output]