[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: raw chat for Wed AM
Simon Holdsworth: 09:00 - 10:30 Conformance statements and testing o What form should conformance statements in the specs take? o Approach to updating specs to make conformance statements conform o Overall approach for tests, how to define tests o Input from Assembly TC o Testing subcommittee o Walkthrough specs identifying conformance issues 10:30 - 10:45 Break 10:45 - 12:00 Open issue discussion 12:00 - 13:00 Lunch 13:00 - 15:00 Possible new areas of work/open issue discussion o Data binding o Exception handling o New bindings o Continue open issue discussion 15:00 - 15:15 Break 15:15 - 16:45 Plan of work, targets for spec completion o Deadlines for committee drafts for each binding spec o Criteria for specs being complete 16:45 - 17:00 o Summary of the meeting 17:00 Close Simon Holdsworth: 09:00 - 10:30 Conformance statements and testing o What form should conformance statements in the specs take? o Approach to updating specs to make conformance statements conform o Overall approach for tests, how to define tests o Input from Assembly TC o Testing subcommittee o Walkthrough specs identifying conformance issues 10:30 - 10:45 Break 10:45 - 12:00 Open issue discussion 12:00 - 13:00 Lunch 13:00 - 15:00 Possible new areas of work/open issue discussion o Data binding o Exception handling o New bindings o Continue open issue discussion 15:00 - 15:15 Break 15:15 - 16:45 Plan of work, targets for spec completion o Deadlines for committee drafts for each binding spec o Criteria for specs being complete 16:45 - 17:00 o Summary of the meeting 17:00 Close anonymous morphed into Piotr Przybylski TomRutt: Topic: Discussion of Conformance Statements TomRutt: Martin: deciding on "MUST" vs "MAY" is not always editorial, and people sometimes have strong conflicting opinions on the proper choice. TomRutt: Mike R: we may want to wait until the assembly TC has made some progress on conformance targets and statements TomRutt: Mike R: what are the conformance targets in scdl, what are the run time conformance targets? TomRutt: Martin: what does it mean to conform to an entire web service binding document? TomRutt: Martin: this is a cross TC problem, bindings are actually sections in the assembly spec TomRutt: Simon H: target is often sca runtime TomRutt: Martin: in order to conform to a binding the run time must do ... TomRutt: Dave B: SCA binding implementation, or SCA binding run time environment TomRutt: Martin: and TomRutt: Martin: "an SCA runtime that supports the web service binding" TomRutt: Mike R: JMS binding spec has some runtime requirements TomRutt: section 7.1 of JMS binding uses "SCA runtime" as a target TomRutt: Mike R: sometimes referred to as "binding instance" TomRutt: Mike R: "the binding must" statements are on the document as an artifact TomRutt: Mike R: then "this document puts a constraint on the SCA Runtime" , then "the SCA runtime must" TomRutt: Mike: references tell the runtime that it has to send messages in a particular manner TomRutt: Discussion on "message" conformance vs "JMS Runtime" conformance statementw TomRutt: Anish: scdl file itself may be a target. I like wsi style where each conformance statement has a single target, with a single RFC 2119 keyword in it TomRutt: Martin: each binding has three targets: 1) the x-binding is a target (artifacts including scdl files and schema descriptions) 2)SCA runtime is another target, constrained by artifacts, 3) any technology specific artifacts (e.g., messages, soap headers) TomRutt: Martin moved to resolve issue 17 with the above resolution, seconded by Mike R. TomRutt: s/issue 17/issue 14/ TomRutt: Mike R: change example (artifacts included in scdl files) TomRutt: change "each binding has three targets" to "each binding spec has at least three targets" TomRutt: Martin: we want to not have tools be a conformance target, however any generated scdl must conform as an artifact. TomRutt: Simon H: eg: the binding type in a JMS binding file must ... TomRutt: each binding spec has at least three targets: 1) the x-binding is a target (artifacts included in scdl) 2)SCA runtime, constrained by artifacts, 3) any technology specific artifacts (e.g., messages, soap headers) TomRutt: 1) binding.x elements and binding type definitions in scdl files TomRutt: 1) binding.x elements in scdl definitions and binding type definitions in scdl TomRutt: 1) binding.x elements and binding type definitions in scdl TomRutt: each binding spec has at least three targets: 1) binding.x elements and binding type definitions in scdl 2)SCA runtime 3) any technology specific artifacts (e.g., messages, soap headers) TomRutt: Eric: do we have any deployment conformance targets? TomRutt: deployment is caught by conformance to sca runtime TomRutt: Motion recorded as: each binding spec has at least three targets: 1) binding.x elements and binding type definitions in scdl 2)SCA runtime 3) any technology specific artifacts (e.g., messages, soap headers) TomRutt: No objections, motion passes to resolve issue 14 TomRutt: Martin: moves to close issue 14 with the above resolution, second by Tom TomRutt: Martin: this gives us a template for each binding type. Each binding spec has to have the specific "x" targets defined. TomRutt: Martin: we should direct editors to propose rfc 2119 wording, including the proper targets. TomRutt: Martin: we need to identify the artifacts that are conformance targets TomRutt: Mike R: there are action items that come off of this resolution. Each spec will say, for example, "Any SCA runtime that claims to support this binding must abide by the requirements of this specification" TomRutt: Mike R: putting this statement at the top of the document eliminates the need to state it repeatedly throughout the document TomRutt: Martin: move to ammend to add: All binding specifications must include the statement "Any SCA runtime that claims to support this binding must abide by the requirements of this specification" TomRutt: Dave B seconded ammendment. TomRutt: Martin: we have to add action items to have the editors add this text to existing binding specs TomRutt: No objections to approve ammendment. TomRutt: No objections to approve amended motion. Issue 14 closed with agreed resolution. TomRutt: Discussion on need to Add action item to the editors to add sentence to existing binding specs TomRutt: Resolution: each binding spec has at least three targets: 1) binding.x elements and binding type definitions in scdl 2)SCA runtime 3) any technology specific artifacts (e.g., messages, soap headers) All binding specifications must include the statement "Any SCA runtime that claims to support this binding must abide by the requirements of this specification" TomRutt: Agreed to add this as a new action item: editors to add new sentence to existing binding specs. TomRutt: Martin: we should direct the editors to start working on writing the conformance claims in their documents using this new template. We should probably have this be done in a staged manner TomRutt: Mike R: JMS spec could be first. TomRutt: Action on Simon H to apply this template to the JMS binding spec to produce a working draft. TomRutt: Martin: each editor should feel free to start applying the template to their specs in a staged manner for review by the TC TomRutt: Topic: Testing TomRutt: Martin: Jacques gave a presentation at the f2f regarding writing of test assertions and machinery to evaluate them. TomRutt: Anish: assembly TC will produce the initial framework, which the binding tc and contribute into TomRutt: SCA runtime conformance can sometimes include test assertions on output messages based on parameters of input messages. This requires a message log produced by the SCA runtime on a test scenario. anish: non public link to assembly testing proposal: http://www.oasis-open.org/apps/org/workgroup/sca-assembly-testing/email/archives/200803/msg00001.html anish: here is the public link: http://lists.oasis-open.org/archives/sca-assembly-testing/200803/msg00001.html TomRutt: We may have to have test scenarios to run the test assertions against. TomRutt: Martin: we can start compiling a table of test assertions needed and the conformance requirements as two axis TomRutt: Anish: let the assembly go thru this a few times, and get it correct before we further refine it TomRutt: Anish: let the assembly go thru this a few times, and get it correct before we further refine it TomRutt: General agreement with Anish sentiment, this TC will wait for assembly to make progress TomRutt: Topic: Data Binding TomRutt: Mike R: references mapping to resource adapter is at domain level. Not different per use. TomRutt: Simon H: the tc must determine if there are any aspects of this data binding in the scope of standardization. TomRutt: Simon H: is there agreement that we need something more than we have now regarding data bindings, and that we should open a new issue on this topic. TomRutt: General agreement expressed to add new. Simon Holdsworth1: Recess until 11:30 Simon Holdsworth1: Meeting resumed Bryan Aupperle: Please dial back in Dave Booz: Simon is doing it Simon Holdsworth1: redialled TomRutt: additional configuration can be a subtype of the binding, corresponding to this extra configuration style TomRutt: Simon H: Discussion on vendor specific sub-typing of bindings being desirable TomRutt: Mike TomRutt: Mike R: some subtyping mechanisms may be common enough to warrant standardization. We can give them common labels and semantics. TomRutt: Simon H: do we standardize 2% cases, or wait till 20% usage level before standardization? TomRutt: Discussion of xsi type vs subtyping TomRutt: Dave B: put wrapper around non portable aspect of data binding TomRutt: Question on how many use cases will require custom data binding. (more than 1/2, less than 80%) TomRutt: Simon H: may need adaptation to match between different implementation types (e.g java component to Bpel component) TomRutt: Eric J: differentiation between modeling as bag of name value pairs, vs specific set of parameters. TomRutt: Mike R: some people like strongly typed data representation, some like loosely typed data representation, neither is specific to SOA principles. TomRutt: Simon H: do not want details of how transport works to have influence TomRutt: Mike R: where we are now: have xsd any stating your data binding goes here (as extensibility element) TomRutt: Mike R: there can be more strategies we can standardize, less value in standardizing additional things. Not in favor of a new element definition which contains only "any" children. TomRutt: Mike R: some level of agreement on a sub element of binding called dataBinding, with no attributes or sub elements other than xsd any's. There is an open question as to whether that dataBinding element should be used directly or via subtypes thru substitution groups. Another question on how many standardized versions of these dataBindings there are. At least the one that we have now. TomRutt: Mike R: most implementations would have a custom data binding mapping to a class. TomRutt: Mike R: if enough buy in, we could have a resolution and two open issues. Introduce dataBinding subelement (of what is open). Have dataBinding subelement of JMS binding, intended to hold data about how data binding is done. Michael Rowley: s/data/configuration Michael Rowley: The dataBinding element has no attributes or subelements, only wildcards. Michael Rowley: Issues: Michael Rowley: 1) How many other bindings should have this (or should they all)? Michael Rowley: 2) Should they be customized through substitution groups (e.g. dataBinding.foo) Michael Rowley: 3) What standardized dataBindings should exist beyond the one listed currently in the JMS spec. TomRutt: Agreed to have this recorded as a single new issue, with three or four questions TomRutt: MIke R took action to send the new issue proposal to the list TomRutt: MIke R:operation selection should probably be done in a similar way. TomRutt: Dave B: trying to separate these into two separate things might cause a problem TomRutt: Discussion on operation specific data binding TomRutt: May need fourth question on operation specific data binding (resolution needs to address operation selection) TomRutt: Recessed at 12:35 for lunch -- Tom Rutt Tel: +1 732 801 5744 Fax: +1 732 774 5133 email: tom@coastin.com; trutt@us.fujitsu.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]