OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Raw chat minutes for 2009-04-23



Simon Holdsworth: Audio conference: 

Meeting Number: * 913929 * (press * before and after the digits) 

Phone numbers: 

Austria = Vienna 026822056419 
Belgium = Brussels 022901709 
China Toll Free = China North 108007121722, China South 108001201722 
Denmark = Copenhagen 32714982 
France = Paris 0170994364, Lyon 0426840196, Marseilles 0488915310 
Germany = Berlin 030726167296, Frankfurt 069710445413, Hamburg 040809020620, Munich 089244432767, Stuttgart 0711490813212, Dusseldorf 021154073845 
India Toll Free = 0008001006703 
Ireland = Dublin 014367612 
Italy = Milan 0230413007, Rome 06452108288, Turin 01121792100 
Japan = Tokyo 0357675037 
Netherlands = Amsterdam 0207965349 
Portugal = Lisbon 211200415 
Russia Toll Free = 81080022074011 
Spain = Barcelona: 934923140, Madrid: 917889793 
Sweden = Stockholm 0850520404 
Switzerland = Geneva 0225927186 
UK Toll Free = 08003581667 
UK Toll = London 02071542988, Manchester 01612500379, Birmingham 01212604587 
USA Toll Free = 18665289390 
USA Toll = 19543344789
Simon Holdsworth: Agenda
Simon Holdsworth: 1. Opening 

Introductions 
Roll call 
Scribe assignment 

Top 10 on the scribe list: 
Tom Rutt Fujitsu Limited 
Jeff Mischkinsky Oracle Corporation 
Plamen Pavlov SAP AG 
Martin Chapman Oracle Corporation 
Eric Johnson TIBCO Software Inc. 
Piotr Przybylski IBM 
Simon Nash Individual 
Anish Karmarkar Oracle Corporation 
Ashok Malhotra Oracle Corporation 
David Booz IBM 

Agenda bashing 

2. Approval of the minutes from 16th April 

http://www.oasis-open.org/committees/download.php/32156/SCA%20Bindings%20minutes%202009-04-16.doc 

3. Actions 

20090211-4 [General] Write up HTTP binding use cases 
20090311-2 [Editors] Update specs for new assembly namespace 
20090312-1 [Editors] Update schemas in specs as per http://lists.oasis-open.org/archives/sca-bindings/200903/msg00057.html 

4. New Issues 

Please note, as per resolution on 9th October 2008, new issues received on the mailing list after Noon GMT 1st November can only be opened using the same voting rules as re-opening a closed issue (2/3 majority of a full TC vote) 

no new issues 

5. Open Issue Summary/Schedule 

Discuss ownership/deferral of issues. 

Current schedule: 

Must have issues resolved by April 16th 
Public review draft available for TC comments April 23rd 
Public review draft vote April 30th 
Test assertions complete one month beyond PRD, test cases one month after that. 

Issues with proposed resolutions: 5 
Issues with identified owner, no resolution: 0 
Issues with no identified owner: 0 

Survey outlook for issues with no proposed resolution (marked with * in this list) 

Simon Holdsworth: 48 (pri 3) 
Anish Karmarkar: 2 (pri 2), 25 (pri 1) 
Eric Johnson: 54 (pri 1) 
Simon Nash: 23 (pri 1) 

6. Conformance statement numbering 

Discuss/agree on the updates to the specs for issues 61, 62, 63. 

http://www.oasis-open.org/committees/download.php/32160/sca-binding-ws-1.1-spec-cd02-issue61-rev3.doc 

http://www.oasis-open.org/committees/download.php/32159/sca-binding-jms-1.1-spec-cd02-issue62-rev2.doc 

http://www.oasis-open.org/committees/download.php/31989/sca-binding-jca-1.1-spec-cd02-issue63.doc 

7. Open Issue Discussion 

http://www.osoa.org/jira/browse/BINDINGS-25 
Is it required that every implementation of binding.ws support the soap intent? 
Raiser: Anish Karmarkar, owner: Anish Karmarkar 
Priority: 1 
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200904/msg00072.html 

http://www.osoa.org/jira/browse/BINDINGS-23 
@wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs 
Raiser: Eric Johnson, owner: Simon Nash 
Priority: 1 
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200904/msg00000.html 

http://www.osoa.org/jira/browse/BINDINGS-54 
Endpoint URI algorithm is unclear 
Raiser: Eric Johnson, owner: Eric Johnson 
Priority: 1 
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200903/msg00104.html 
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200903/msg00107.html 

http://www.osoa.org/jira/browse/BINDINGS-2 
How should SCA callback semantics be carried over Web Services? 
Raiser: Simon Nash, owner: Anish Karmarkar 
Priority: 2 
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200904/msg00012.html 
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200904/msg00038.html 

http://www.osoa.org/jira/browse/BINDINGS-48 
How are mayProvide intents on bindings satisfied 
Raiser: Ashok Malhotra, owner: Simon Holdsworth 
Priority: 3 
Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200903/msg00005.html 
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200903/msg00059.html 

7. AOB 

------------------------------------------------------------------- 

*Revolving list of scribes* 

Tom Rutt Fujitsu Limited 
Jeff Mischkinsky Oracle Corporation 
Plamen Pavlov SAP AG 
Martin Chapman Oracle Corporation 
Eric Johnson TIBCO Software Inc. 
Piotr Przybylski IBM 
Simon Nash Individual 
Anish Karmarkar Oracle Corporation 
Ashok Malhotra Oracle Corporation 
David Booz IBM 
Bryan Aupperle IBM
Eric Johnson: Scribe: Eric Johnson
Eric Johnson: Topic: approving minutes
Eric Johnson: No objections to approving the minutes, minutes approved.
Eric Johnson: Topic: actions
Eric Johnson: Simon H: Unaware of any progress.
Eric Johnson: Topic: Open issues
Eric Johnson: Simon H: Want to revisit conformance statement numbering.
Eric Johnson: ... Main objective - are we sufficiently happy with these documents that we can use them as basis for applying open issues.
Eric Johnson: ... Had some feedback which has been integrated.  Like to hear from others on updates.
Eric Johnson: Simon N: Happy with changes made - noted editorial typos which I can send after the call.
Eric Johnson: Simon N: Move accept this document as the resolution to issue 61.
Eric Johnson: Mike E: 2nds.
Eric Johnson: Simon H: Issue 61 already resolved.
Eric Johnson: Simon N: I amend my motion to accept the proposed document as CD02-rev1.
Eric Johnson: Tom Rutt: 2nds
Eric Johnson: Simon H: Any objections to the amendment?
Eric Johnson: Amendment passes with no objections?
Eric Johnson: Amended motion passes with no objections.
Eric Johnson: Simon H: Any comments on the other two documents.
Eric Johnson: (Admissions on the phone that people haven't looked at JMS and JCA documents....)
Eric Johnson: Topic: Open issues.
Eric Johnson: Subtopic: Bindings 25
Eric Johnson: Anish: Sent out version 2, got comments, sent out version 3.  Typo in version three that Simon N has pointed out.
Eric Johnson: ... major changes between version 1 & 2.  Getting rid of typos, removing RFC keywords not intended as such, reducing redundancy, removing error related to reference to constraining types
Eric Johnson: ... modeled conformance section after Java spec.  Defined two categories for conformance reflected in sections 5.1 & 5.2.  Added authoritativeness of schema
Eric Johnson: ... moved requirement for schema conformance to section 2, changed req. on runtime to reflect requirements that don't appear in schema
Eric Johnson: Mike: Note that fonts have been changed - so editors should use caution in merging.
Eric Johnson: ... proposing to make endpointReference an optional feature - notion isn't elsewhere in SCA specs.
Eric Johnson: Anish: Yes, we've discussed this before, and on a previous call we thought there might be implementations that might not require referenceParameters.
Eric Johnson: Mike: If a document shows up with endpointReference - what is the runtime supposed to do if this element shows up and doesn't support this?
Eric Johnson: Anish: I think you're right - need to state whether this is ignored or rejected.
Eric Johnson: ... think we should do "reject" option.
Eric Johnson: Simon N: I agree - I think we should reject.
Eric Johnson: Mike: Agree, if it is not supported, it is important to reject it.
Eric Johnson: ... otherwise the person creating the composite gets a surprising result.
Eric Johnson: Anish: For anything that is optional, we perhaps should be rejecting if not supporting.
Eric Johnson: Mike: We should probably have an explanation here.
Eric Johnson: Anish: What are the use cases again?
Eric Johnson: Simon N: A runtime that doesn't want to deal with reference parameters.
Eric Johnson: Eric: There might be security concerns around having reference parameters, and it may be safer for a runtime simply not to allow them.
anish: How about: If an SCA runtime does not support the element <endpointReference>, then it MUST reject a document that contains it. ?
Eric Johnson: Mike: The paragraph underneath needs to say something about this optionality.  We will need to say something about a runtime that accepts everything, and a runtime that might not support these parameters.
Eric Johnson: Simon N: Why do we need to make that distinction?
Eric Johnson: Mike: For the kind of runtime that doesn't want to support WS-Addressing, what else might be optional?
Eric Johnson: Anish: Runtimes that don't do the shoulds, and runtimes that do everything - can we deal with this in the test suites? Runtimes that say they pass A & B, and some runtimes that just pass A.
Eric Johnson: Mike: I disagree.  We have to specify what "A" and "B" are.  It may be at the moment this is the only thing that is optional...
Eric Johnson: Anish: Proposed resolution of issue #2 is optional.
Eric Johnson: ... The notion of "should" captures this already, doesn't this?
Eric Johnson: Mike: potential mishmash of runtimes is problematic.
Eric Johnson: ... we should have a small set of well defined runtimes.  We should create profiles.
Eric Johnson: Tom Rutt: Conformance classes.
Eric Johnson: Simon N: This is getting quite complicated.  If we had multiple shoulds that need to be tied together.  This is increasing combinatorial complexity, but not by much.
Mike Edwards: 6 optionals = 2**6 combinations
Eric Johnson: ... if we can group these together, then profiles make sense.
Eric Johnson: ... otherwise we could let the should stand alone.
Eric Johnson: ... at the very least we need to make a change to see what the runtime does if it encounters this element and doesn't support it.
Eric Johnson: ... perhaps we need to agree on the direction for the rest of it?
tom rutt: is the phone connection still up?
Simon Nash: it is for me, Tom
Ashok: yes, Tom
tom rutt: I will redial sorry
Eric Johnson: Anish: I proposed language above, does that work for everyone.
Eric Johnson: Mike: Yes.
Eric Johnson: Martin: MAY and SHOULD are slightly different
Eric Johnson: Simon N: If the SHOULDs don't build on top of each other, then how can we make profiles?
Eric Johnson: Martin: If they're really orthogonal, then profiles don't help.
Eric Johnson: Simon N: We only need a profile thread if these things are aligned.
Eric Johnson: Mike: 4 SHOULDS in assembly spec deal with documents, 5 deal with how errors are reported. one on the runtime.
Eric Johnson: Anish: Should produce an error as per text I proposed above.
Eric Johnson: Simon N: If we're rejecting documents without this element, then there is no other "SHOULD" that could be combined with it anyway.
Eric Johnson: ... If we don't specify what to do when it isn't supported, and there's another SHOULD, then we'd have a point of discussion about how to deal with these.
Eric Johnson: Simon H: Mike, can we deal with this as a separate issue?
Eric Johnson: Mike: Yes, if we come across other shoulds, we can figure out how they can be treated.
Eric Johnson: Simon H: Is the additional statement sufficient for resolving this issue?
Eric Johnson: Simon H: Want to get a resolution.
Eric Johnson: (Anish continues going through document...)
Eric Johnson: Anish: We have another SHOULD statement in section 2.6...
Eric Johnson: ... maybe we should have a requirement that if there are unsupported WSDL extensions, then you must reject the SCA document?
Eric Johnson: Simon N: More debatable here whether or not it needs to be rejected - suppose both SOAP 1.1 & 1.2 bindings appear, and an unsupported extension in one, why reject the whole document?
Eric Johnson: Anish: Why not impose that absolutely required items be rejected - flagged by wsdlRequired.
Eric Johnson: ... SOAP 1.1 & SOAP 1.2 are extensions to WSDL - but nobody uses wsdlRequired to flag that one must be supported.
Eric Johnson: Simon N: We do have intents that could choose.
Eric Johnson: Mike: Prepared to accept that runtime doesn't support soap 1.2.  What I would prefer the SOAP_1.1 and SOAP_1.2 intents - valid to specify in the SCDL, but the runtime can still fail to run.
Eric Johnson: ... I prefer a different "cut" - both intents must be recognized, but valid to choose not to run them.
Eric Johnson: Anish: I hope there's a requirement in the policy spec that takes care of that.
Eric Johnson: Mike: Slightly different statement - this intent is defined, so you must recognize it.  But whether you can find a combination of binding and policy that will implement, or whether it fails.
Eric Johnson: Anish: We don't require that runtimes support transactional intents.
Eric Johnson: Dave: The document isn't rejected by the presence of unsupported intents, but no requirement that the runtime can satisfy the intent.
Eric Johnson: Mike: Could easily have a binding that doesn't support a recognized intent.  Pure JMS binding with soap intent, for example.
Eric Johnson: ... if you have binding.ws, soap_1.1 intent it will work, it will be provided.  I can express soap_1.2 intent, but it may not go into production.
Eric Johnson: Dave: Statement o
Eric Johnson: Dave: Statement of 181-182 is not needed?
Eric Johnson: Anish: it is needed.
Eric Johnson: Mike: Part of the trouble is around the meaning of the word "support."
Eric Johnson: Dave: lines 181-182 doesn't add anything over 168-173.
Eric Johnson: Mike: Different way to express.  A binding indicates what it supports via its "alwaysProvides" and "mayProvide".
Eric Johnson: Anish: Cannot mandate what's a part of alwaysProvides.
Eric Johnson: Simon N: We cannot mandate that the user write things in definitions.xml
Eric Johnson: Dave: Runtime must indicate something.
Eric Johnson: Anish: These intents must appear either in alwaysProvides or mayProvide.
Eric Johnson: Simon H: We've run out of time.
anish: Section 2.8: how about "The SCA runtime MUST include the SOAP.1_1 intent either in the alwaysProvides or mayProvides attribute of the definitions infoset"
Dave Booz works for me



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]