Minutes
Opening
Roll call - 18/26 = 69% Quorate
Agenda accepted w/o change
Approval of minutes 2009-10-13
Resolution: Minutes of 2009-10-13 approved w/o
Action items
Action: id=2009-10-13-1 status=done owner="MikeE" Provide updated proposal for ASSEMBLY-143
Action: id=2009-10-13-2 status=done owner="MikeE" Provide updated proposal for ASSEMBLY-138
Administrivia
Public review of test matierials finished on 2009-10-17
Have received a few public comments, but many more from TC members
MikeE:
Would now like to get spec completed and then update Test suite (but work on both)
Existing Issues
<Mike Edwards>
Latest email:
DaveB:
Mike & I were supposed to discuss but travel has prevented propose postponing discussion
Chairs agree - no objections
<Mike Edwards>
Latest proposal:
MikeE:
Reviews latest proposal (above)
Add new section at end of 11 - describe "states" of artifacts
...add normative statements wrt artifact states
...and when errors can be reported
MartinC:
Similar discussion in Java TC - are these states consistant with theirs?
MikeE:
Java has more and more detailed states - but not really installed or deployed
...don't think there are any inconsistencies
DaveB:
(Java TC Chair) Think this is OK
MarkC:
(Java TC Chair) Also think this is OK
AnishK:
Concerend about "... given to runtime to EXECUTE" - don't like this
...not all artifacts are executeable
<anish>
Deployed artifacts are artifacts that are available to the SCA runtime to be run.
MikeE:
Happy with this proposed wording
Motion: m=MikeE s=DaveB Text as immediately above
No discussion - No objections
Resolution: Resolve ASSEMBLY-138 with text in E-mail ammended as in minutes of 2009-10-20
MikeE:
Several approaches
...1) As described at present - must support SCA "approved" implementation languages
...2) Can support any language BUT must have publicly available description of the implementation AND
...must be a publically available version of the Test Suite
<anish>
implementation.abap ;-)
MartinC:
Agree with the informal meaning of "publically available" but don't think OASIS can dictate terms to vendors
...(Open source or other, paid means of access to code)
SanjayP:
Agrees with Martins comments
AnishK:
There will be problems with some langauages being able to support some features - eg Wired by impl
...not all languages can do this - so how can C&I spec's determine conformance
MikeE:
That would be covered by implementation description doc
...and we would have to decide how to handle these cases
...This will be a non-trivial task
...TC would have to decide if these implementation(s) are valid
<anish>
copy-lefting our test suite code?
PeterF:
There could be conforming implementations that were not useful and/or vice versa
MikeE:
Also problems with Test Suites - what parts are valid for which implementations
...there are already issues with requiring implementation dependent testing in SCA Assembly
<anish>
without looking at the specific proposal it is hard to say, but certain kind of copy-lefting will be problematic for corporations
because of the potential viral-effect to their commercial product
SanjayP:
Document that descibes how SCA concepts are mapped to language should be publically available
...not necessarily details of (propreitary) langauge but how that language supports SCA
MikeE:
Is consensus that documents MUST exist but MAY not be publically available
...ie maybe only to customers commercially
MikeE:
The issue is that conformance is judged by "community"
...so if documents & test suite are not publically available how can conformance be judged
MarkC:
Could we say "must be delivered as part of the product"?
<Peter Furniss>
my comment earlier "There could be conforming implementations that were not useful and/or vice versa"
MartinC:
Compromise by stating "minimum set of supported featuree" and for full SCA "blessing" language should be submitted to OASIS
<Peter Furniss>
my belief is there WILL be one or the other. It is impossible to write conformance requirements such that the set of useful
and set of conformant are identical
Discussion on direction as there could be a lot of work involved
SanjayP:
How about implementation.MyJava as a subset of SCA Java implementation?
<anish>
it is a balance between avoiding embrace-and-extend and making SCA popular and successful and allow ppl to innovate
EricW:
Wouldn't this only work for subsets? How would C# work or some propreitary language?
Motion: Maintain status quo for conformance requirements m=MikeE s=DaveB
This motion implies ASSEMBLY-132 would not be resolved
SanjayP:
Don't think this is acceptable we need to address these issues
Action: owner=SanjayP Send E-mail describing alternative approach for ASSEMBLY-132
motion expires due to lack of time
AOB
<Mike Edwards>
thanks Eric
Meeting RECESSED at 9:02AM PDT until 2009-10-21
NP Mike - I can scribe tomorrow as well as I don't think Bob can attend
Resumption of Session
<Scott>
+1 to f2f on agenda
<Scott>
also eventing issue handling, please
Additional Roll - DaleM PeterN MurtyM Sabin
Agenda
Add topics - Event F2F, Issue Handling for Eventing
Issue Handling for Eventing
MikeE:
Create separate component in JIRA to log against
AnishK:
Can't we just rev the version?
MikeE:
Found it easier to use componet (for testing)
Action: owner=ScottV status=done Create JIRA component for Event Handling Issues
AnishK created component in real-time
<anish>
can't 80 be closed with a decision that event proc. will be part of 1.2?
MartinC:
Can we close ASSEMBLY-80 or move it to new component
<anish>
cause i anticipate that we'll have number of issues on event process.
MikeE:
ASSEMBLY-80 is deferred at present(?)
Motion: m=AnishK s=ScottV Close ASSEMBLY-80 with resolution that Eventing Pub/Sub will be provided in SCA Assembly version 1.2
moved by AnishK second ScottV
Resolution: Close ASSEMBLY-80 with resolution that Eventing Pub/Sub will be provided in SCA Assembly version 1.2 w/o
SCA Eventing F2F
Too short notice for early November
Thanksgiving rules out last week
Leaves week starting 16th (or 9th)
MartinC:
Would be advantageous to align with W3C TPAC (West Coast)
ScottV:
TIBCO can host and will prepare material for discussion on our POV
<Peter Niblett>
I can't do week of 16th
Tentative agreement for week begining 2009-11-09
MikeE:
Would also like to finish 1.1 to get it out the door
EricW:
If theres no SCA Policy meeting it wouldn't be fair to overwrite their telecon
<anish>
here is my suggestion: if it is 3 days: tu-we-th; if it is 4 days: mo-tu-we-th
AnishK:
Cannot do that week - hosting another meeting in Portland
(Further calendar discussions)
Agreement Tue,Wed,Thu 2009-12-1 thru 2009-12-3 (pending confirmation)
Chairs request objections to be notified by next Tuesdays call 2009-10-27
Discussion
MartinC:
Agreed four positions:
1: the current SCA 1.1 model needs tweaking/adding to, to support a pub/sub paradigm
2: SCA 1.1 use of WSDL has certain assumptions in assemblers/developers heads (and current tooling), which need re-examining
for pub/sub
3: SCA 1.1 wires and wiring may be too restrictive for pub/sub and need to be relaxed/extended
4: We agreed that we should talk about whether an assembler looking at SCDL should be able to distinguish between events and
one-way requests
MartinC:
Need (at present) to move away from discussion WSDL (again)
<anish>
looks like we are back to discussions from last week :-)
<anish>
like interface matching
<anish>
perhaps because it is central to the different POVs
MikeE:
Don't like putting pub/sub into binding - requires replacing model if the transport changes
<Mike Edwards>
+1 on the channel concept being represented in the model
ScottV:
Agrees with Mike and also thinks there's got to be some sort of channel mechanism
AnishK:
Seem to be in agreement on Positions 1 & 3
<anish>
the current model makes bindings interchangeable (at least in the model)
<anish>
saying that do it in a binding-specific way doesn't work
MartinC:
Binding should be used to map SCA onto specific technologies - not introduce new semantics
MikeE:
Service can have more interfaces than reference uses
...Consumers can accept more events than a Producer produces
...these are more or less the opposite of each other
General agreement on need for a "channel"
MartinC:
Current wiring is too restrictive to provide a channel
...either relax current wiring rules or add new artifacts for channel
...prefers a not to tweak existing wiring
PeterN:
Agree with adding a channel - but there are different requirements for events and pub/sub
ScottV:
Agrees there is more to a channel than just simple pub/sub
...we should get agreement on need for a channel without tying to specifics at this stage
AnishK:
Isn't event vs pub/sub an implementation detail?
PeterN:
There's (usually) a dynamic aspect to pub/sub that is not captured by simple events
MikeE:
We should not rule out the dynamic aspect
DaleM:
"Channel" is a bit of a loaded term - we want to look at this without taking on these assumptions
<Martin C>
dale isn't that a channel binding issue maybe?
<Peter Niblett>
By "dynamic" I meant the ability of a consumer to be subscribed in at runtime, rather than have its connection defined in
the assembly. And if there is the capability for dynamic subscription like this, are there any constraints imposed by the
assembly?
<anish>
ah, i thought that is what you meant. We currently have dynamicity wrt assembly -- new subscribers/consumers can be deployed/undeployed
at runtime.
<Peter Niblett>
to Dale's point I favour exposing two levels of channel. "Thin" ones that do the simple routing (possibly 1->many) and also
the thicker richer kind
<Peter Niblett>
which are explicitly modelled
DaleM:
Does the channel provide any services, etc? I.E. Thick or thin?
<anish>
peter, how would the subscriber get hold of the info that would be needed to subscribe?
<Martin C>
we need to define abstract semantics of a channel then use binding to map down
AOB
<anish>
or do you want some sort of wired-by-impl capability?
<Martin C>
any stragglers - sorry
Martin can you add the link to the roll?
Meeting adjourned 10:01AM PDT
<Peter Niblett>
agree with Martin - we shouldn't have the binding imposing additional semantics that conflict with the abstract level.
<Peter Niblett>
Anish, I agree that there's that question.. it could either declare an interest in something and then have the subscription
automatically created (it kind of assumes that there's something out there) or it has access to a registry service that tells
it who has what. But I think this is going rather beyond the scope of what we need to specify right now
<Peter Niblett>
the reason I asked the question wasn't really to say "we should do all this", it was more to check whether there were people
who thought that that's what we are talking about
<Mike Edwards>
Right - a bit more extensive than we need for the present, I think.
Issues log - Opened 0 Closed 1
<Peter Niblett>
because that's what "publish/subscribe" means to some people
Schreiber diagnostics output
[Delete this section before publishing the minutes]
final validation: Title not specified, default title 'OASIS SCA-Assembly TC...' was assumed
final validation: Chair not specified, default chair was assumed
statistics: Schreiber found 184 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 86: s/Couls/Could
edits: Line 233: s/channel/subscriber/
citation-detection-scribed: Line 22: Check for possible unrecognized nick 'ASSEMBLY 143'
citation-detection-scribed: Line 28: Check for possible unrecognized nick 'ASSEMBLY 138'
citation-detection-scribed: Line 52: Check for possible unrecognized nick 'ASSEMBLY-132'
edit-substitute: command on line 86 succeeded, changed line 85 from 'Couls' to 'Could'
edit-delete: Line 86 was deleted
citation-detection-scribed: Line 109: Check for possible unrecognized nick 'Meeting RECESSED at 9'
edit-substitute: command on line 233 succeeded, changed line 232 from 'channel' to 'subscriber'
edit-delete: Line 233 was deleted
citation-detection-scribed: Line 241: Check for possible unrecognized nick 'Meeting adjourned 10'
command-autoroll/oasis: Line 249: Attempting to fetch roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=25349
command-autoroll/oasis: Line 249: Successfully fetched roll from http://www.oasis-open.org/apps/org/workgroup/sca-assembly/event.php?event_id=25349
system: Transformer: SAXON 9.1.0.7
[End of Schreiber diagnostic output]