Minutes
<Bob>
eric, are you there?
Opening
<Mike Edwards>
Thanks for sribing Eric
<Mike Edwards>
or even scribing
Agenda - accepted as posted
Approval of Minutes
Resolution: Minutes of 2011-03-22 approved w/o
Action Items
Action: id=2010-09-22-8 status=pending owner="EricJ" produce new proposal for ASSEMBLY-227
Action: id=2011-01-04-2 status=pending Edwards to write a new proposal for the resolution of Assembly-246 along the lines contained
in wsra
EricJ:
Notes that new issues to be considered have impact on his AI
Aministrivia
Exit Criteria
MikeE:
Notes previous discussions, but no significant progress
...does not porpose to discuss until there seems to be progress via E-mail
Open Issues (1.1)
ASSEMBLY-260 Remove RFC2119 language for underspecified normative statements
MartinC reviews his proposal
MartinC:
"Quick & dirty" way of removing "optional" RFC2119 from spec
...e.g. why have untestable statements as normative text?
Change: "[ASM12008] An SCA runtime MAY provide the contribution operation functions (install Contribution, update Contribution,
add Deployment Composite, update Deployment Composite, remove Contribution)."
To: "It is strongly encouraged that an SCA runtime provides the contribution operation functions (install Contribution, update
Contribution, add Deployment Composite, update Deployment Composite, remove Contribution); how these are provided is implementation
specific."
MartinC:
Probaly use "ought to" instead of "can"
Change: "[ASM12013] For components at the Domain level, with references for which @autowire="true" applies, the behaviour
of the SCA runtime for a given Domain MUST take ONE of the 3 following forms:
1) The SCA runtime disallows deployment of any components with autowire references. In this case, the SCA runtime MUST raise
an exception at the point where the component is deployed.
2) The SCA runtime evaluates the target(s) for the reference at the time that the component is deployed and does not update
those targets when later deployment actions occur.
3) The SCA runtime re-evaluates the target(s) for the reference dynamically as later deployment actions occur resulting in
updated reference targets which match the new Domain configuration. How the reconfiguration of the reference takes place is
described by the relevant client and implementation specifications."
To: "For components at the Domain level, with references for which @autowire="true" applies, the behaviour of the SCA runtime
for a given Domain is implementation specific although it is expected that ONE of the 3 behaviours below is followed:
1) The SCA runtime disallows deployment of any components with autowire references. In this case, the SCA runtime can raise
an exception at the point where the component is deployed.
2) The SCA runtime evaluates the target(s) for the reference at the time that the component is deployed and does not update
those targets when later deployment actions occur.
3) The SCA runtime re-evaluates the target(s) for the reference dynamically as later deployment actions occur resulting in
updated reference targets which match the new Domain configuration. How the reconfiguration of the reference takes place is
described by the relevant client and implementation specifications."
Change: "[ASM12014] Where <wire/> elements are added, removed or replaced by deployment actions, the components whose references
are affected by those deployment actions MAY have their references updated by the SCA runtime dynamically without the need
to stop and start those components."
To: "Where <wire/> elements are added, removed or replaced by deployment actions, the components whose references are affected
by those deployment actions can have their references updated by the SCA runtime dynamically without the need to stop and
start those components. How this is achieved is implementation specific."
Change: "[ASM12015] Where components are updated by deployment actions (their configuration is changed in some way, which
includes changing the wires of component references), the new configuration MUST apply to all new instances of those components
once the update is complete."
To: "Where components are updated by deployment actions (their configuration is changed in some way, which includes changing
the wires of component references), the SCA implementation needs to ensure that the updates apply to all new instances of
those components once the update is complete."
Change: "[ASM12016] An SCA runtime MAY choose to maintain existing instances with the old configuration of components updated
by deployment actions, but an SCA runtime MAY choose to stop and discard existing instances of those components."
To: "An SCA runtime can choose to maintain existing instances with the old configuration of components updated by deployment
actions, although an implementation of an SCA runtime can choose to stop and discard existing instances of those components."
Change: "[ASM12018] Where a component that is the target of a wire is updated, future invocations of that reference SHOULD
use the updated component."
To: "Where a component that is the target of a wire is updated, an SCA runtime can direct future invocations of that reference
to the updated component."
Change: " [ASM12020] Where a component is added to the Domain that is a potential target for a domain level component reference
where that reference is marked as @autowire=true, the SCA runtime MUST:
. either update the references for the source component once the new component is running.
. or alternatively, defer the updating of the references of the source component until the source component is stopped and
restarted."
To: "Where a component is added to the Domain that is a potential target for a domain level component reference where that
reference is marked as @autowire=true, the SCA runtime can:
. either update the references for the source component once the new component is running.
. or alternatively, defer the updating of the references of the source component until the source component is stopped and
restarted."
Change: "[ASM14001] An SCA runtime SHOULD detect errors at deployment time where those errors can be found through static
analysis."
To: " An SCA runtime is expected to detect errors at deployment time where those errors can be found through static analysis."
Change: "[ASM14002] The SCA runtime SHOULD prevent deployment of contributions that are in error, and raise the error to the
process performing the deployment (e.g. write a message to an interactive console or write a message to a log file)."
To: "An SCA runtime has to prevent deployment of contributions that are in error, and raise an error to the process performing
the deployment (e.g. write a message to an interactive console or write a message to a log file). The exact timing of checking
contributions for errors is implementation specific."
MartinC:
Notes there are other statements that prevent runtime running artifacts that are in error
Change: "[ASM60021]
For the case of an un-wired reference with multiplicity 1..1 or 1..n the deployment process provided by an SCA runtime SHOULD
issue a warning."
To: "For the case of an un-wired reference with multiplicity 1..1 or 1..n the deployment process provided by an SCA runtime
is encouraged to issue a warning."
Motion: Resolve ASSEMBLY-260 with proposal in JIRA with modification posted above m= MartinC s=AnishK
No discussion - no objections
Resolution: Resolve ASSEMBLY-260 with proposal in JIRA with modification posted in chat room
AnishK:
Notes that some of the normative statements are shaded differently from each other (formatted color)
ASSEMBLY-261 Upgrade ASM12017, ASM12030, ASM14004 to be mandatory statements
MartinC:
Thinks these should be mandatory (not an anti-optional campaign!)
Change: "[ASM12017] Where a component that is the target of a wire is removed, without the wire being changed, then future
invocations of the reference that use that wire SHOULD fail with a ServiceUnavailable fault...."
To: "[ASM12017] Where a component that is the target of a wire is removed, without the wire being changed, then future invocations
of the reference that use that wire MUST fail with a ServiceUnavailable fault...."
EricJ:
Why was this looked at - because there's no test case?
MikeE:
There is no test case but no marked untestable
MartinC:
Yes but also because in this case there MUST be an error
MikeE:
Don't think this could be tested as there no standard API for this
AnishK:
Should be OK to have MUST in an untestable statement
DannyV:
If an API is not required then how come we specify something that depends on an API?
<anish>
12017 in its entirety is:
MartinC:
An API isn't needed for this to occur
...maybe we should think of rewording to cover removal of wire "by any means"
MikeE:
Think there's other normative statements that would cover this
DannyV:
Then this would be no-normative
Change: "[ASM12030] For XML definitions, which are identified by QNames, the @namespace attribute of the export element SHOULD
be the namespace URI for the exported definitions."
To: "[ASM12030] For XML definitions, which are identified by QNames, the @namespace attribute of the export element MUST be
the namespace URI for the exported definitions."
MikeE:
Intent is to cover situations that use extensions
EricJ:
Not sure what this is supposed to constrain - target is too vague
...how can tools implement this constraint?
AnishK:
Agrees with EricJ - doesn't seem to reflect intent of consrtaining extensions
...a MUST would cover situation where extensions are used with import/export
Change: "[ASM14004] When an error that could have been detected through static analysis is detected and raised at runtime
for a component, the component SHOULD NOT be run until the error is fixed."
To: "[ASM14004] When an error that could have been detected through static analysis is detected and raised at runtime for
a component, the component MUST NOT be run until the error is fixed."
MartinC:
Can't see any reason why a runtime can be allowed to run a component in error
EricJ:
Static analysis of components can't see whole situation and may give false positive errors
EricW:
I seem to remember that this was discussed at length and "SHOULD" was chosen to allow for incorrect static errors
<anish>
The target is called "SCA Composite Document"
martinC:
We've just removed (de-normatized?) other statements that covered this
...but there should be one rule that says "if there's an error then don't run component"
MikeE:
Notes there was some deliberation over this - we wanted to cover different types of runtime
...would preclude some runtime environments (e.g. within eclipse)
EricJ:
Static analysis really only covers design time errors - at compile time
...doesn't cover "assembly"
<anish>
For a component that is contained in a non-conformant deployed SCA Composite Document, the runtime MUST NOT run the component.
[ASM14004] For runtimes and tools that delay detecting errors that could have been detected through static analysis, cannot
run the erroneous component till it is fixed.
MikeE:
There is a statement that say error MUST be raised so we could rewrite 11.1 11.2 as non-normative?
AnishK:
Add text to the effect that component in error cannot be run until fixed (error resolved)?
<anish>
Fixed: For a component that is contained in a non-conformant deployed SCA Composite Document, the runtime MUST NOT run the
component. [ASM14004] Runtimes and tools that delay detecting errors that could have been detected through static analysis,
cannot run the erroneous component till it is fixed.
MartinC:
If the contribution is invalid should the runtime be allowed to run it?
...what ought the runtime do with errors?
No consensus - needs further discussion
EricW:
Sorry my 'phone dropped
AOB
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Date not specified, the date '2011-03-29' was assumed
final validation: Title not specified, default title 'Oasis SCA-Assembly Teleconference...' was assumed
final validation: Chair not specified, default chair was assumed
statistics: Schreiber found 116 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 151: s/1. Intro/agenda: 1. Intro/
edit-substitute: command on line 151 succeeded, changed line 1 from '1. Intro' to 'agenda: 1. Intro'
command-scribe: Line 6: Scribe 'Eric Wells' is recognized by use of the nick 'EricW'
command-scribe: Line 6: EricW's nick 'EricW' has been selected
citation-detection-scribed: Line 35: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 39: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 42: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 45: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 48: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 51: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 54: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 58: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 62: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 65: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 78: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 99: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 112: Check for possible unrecognized nick 'Change'
citation-detection-scribed: Line 150: Check for possible unrecognized nick 'COB 9'
edit-delete: Line 151 was deleted
system: Transformer: SAXON 9.2.1.2
[End of Schreiber diagnostic output]