[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Raw transcript of the Assembly TC call on 12/11/07
<<Minutes_AssemblyTC_Dec11_07.txt>>
anonymous1 morphed into Khanderao anonymous morphed into Pete Walker anonymous morphed into Ron Barack Mike Edwards: The Duane's are multiplying !! CanadaDuane1: D'oh!!! Mike Edwards: 1. Opening Introductions Roll call Scribe confirmation Agenda bashing 2. Approval of minutes of SCA-Assembly TC meeting of 4th December http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/26385/SCA%20Assembly%20minutes%202007-12-04.html 3. Open Issues ASSEMBLY-6: usage of not promoted references http://www.osoa.org/jira/browse/ASSEMBLY-6 http://lists.oasis-open.org/archives/sca-assembly/200711/msg00074.html ASSEMBLY-11: Define conformance targets http://www.osoa.org/jira/browse/ASSEMBLY-11 4. New Issues ASSEMBLY-31: Wiring from a reference with no binding to a service with a binding http://www.osoa.org/jira/browse/ASSEMBLY-31 5. AOB CanadaDuane1: Wil fix - one second... Mike Edwards: 22/35 - Quorate Sanjay: Scribe: Sanjay Sanjay: Next Topic: Agenda bashing Sanjay: No objections. Approved. Sanjay: MikeE: would like to review open AI Sanjay: ... Dieter was supposed to raise a issue in BPEL TC Sanjay: ... Dieter confirmed his action as done Sanjay: Next Topic: Approval of minutes of SCA-Assembly TC meeting of 4th December http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/26385/SCA%20Assembly%20minutes%202007-12-04.html Sanjay: M: Henning, S: Peter Walker. No objections. Minutes approved. Sanjay: Next Topic: Open Issues ASSEMBLY-6: usage of not promoted references http://www.osoa.org/jira/browse/ASSEMBLY-6 http://lists.oasis-open.org/archives/sca-assembly/200711/msg00074.html Sanjay: MikeE (as a TC member) presents the issue Sanjay: MikeE: The current proposal follows RFC 2119 Sanjay: ... describes the five different ways of defining a target service Sanjay: ... The link above for the proposal is wrong Sanjay: ... Link for the right proposal: Sanjay: ... <Sighs and grunts due to difficulty in finding the right proposal on Kavi> Dave Booz: http://www.oasis-open.org/apps/org/workgroup/sca-assembly/email/archives/200712/msg00012.html Mike Edwards: http://lists.oasis-open.org/archives/sca-assembly/200712/msg00012.html Sanjay: ... this proposal describes six different ways of defining a target service Sanjay: ... MikeE describes further rules on combinations and specifics of each mechanism Sanjay: SimonNash: Not sure if the use of 'MAY' is compliant with RFC 2119 Sanjay: ... intention does not seem to be - implementation optionality Sanjay: 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 Martin: 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. Sanjay: MichaelR: It should be possible to override the binding Sanjay: ... if it is both promoted and overridden Sanjay: ... not sure if this case is actually possible Sanjay: Henning: There is also the case of no binding is specified where binding.sca is assumed Sanjay: ... Suggests - if bindings are specified then one of the bindings must be used Sanjay: MikeE: You can't identify a target attribute and still override it Sanjay: ... ruling out the 'promoted and overridden' case Sanjay: Scott: s/any one/some one Sanjay: Martin: use of 'any one' is fine Sanjay: MikeE: Need to address the case brought up by Henning - no binding is specified Sanjay: MichaelR: It is covered by elsewhere as an implicit assumption of binding.sca anonymous morphed into anish Sanjay: ... 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). Sanjay: MikeE continues to present rest of the proposal ... Sanjay: Martin: why are we using English text instead of schema Sanjay: MikeE: This text relates multiplicity with reference settings Sanjay: ... nothing in schema covers this Sanjay: MichaelR: There is an implication that the six ways of specifying target service can be mixed and matched with the different cases of multplicities Sanjay: ... not sure how to clarify this though Sanjay: MikeE: suggests to proceed with current proposal first Sanjay: ... and deal clarifications seperately Sanjay: MikeE describes the text related to deployment and error generation Sanjay: MichaelR: There are times where error can not be generated until invocation Sanjay: Martin: We need to raise a general issue regarding timing of error generation Sanjay: SimonNash: Next paragraphs seem to address this Sanjay: s/seem/seems Sanjay: 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 Michael Rowley: 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. Sanjay: 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 :-(. Sanjay: 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. Sanjay: 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. Sanjay: SimonNash: We need the same 'no later than' fix for this para too Sanjay: 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 Sanjay: MartinC: Section numbering needs to be fixed Sanjay: MikeE: Editors could fix this Sanjay: Discussion about: Sanjay: 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. Sanjay: MikeE continues with the proposal ... Sanjay: 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). Sanjay: SimonNash: s/MAY/MUST as these are the only two options Sanjay: Henning: What about the binding that need additional data? Sanjay: MikeE: Covered in the previous section Sanjay: MikeE: Moves to accept the proposal with the changes identified on this call Sanjay: SimonNash seconds anish i would prefer if the final proposal is sent to the list Sanjay: ACTION: MikeE to send out an updated proposal to the list Sanjay: Motion carried unanimously Sanjay: Issue ASSEMBLY-6 is resolved Sanjay: Next Topic: ASSEMBLY-11 Sanjay: MartinC: I own an action item related to this issue Sanjay: Next Topic: AoB Sanjay: Straggler roll call Sanjay: MichaelR: I may open up an issue suggesting a specific simplification Sanjay: Meeting closed a 8:59 AM Pacific Time
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]