W3C

WS-Addressing WG Face to Face meeting
3 May 2006

Agenda

See also: IRC log

Attendees

Present
Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Paul Downey (BT)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
David Illsley (IBM Corporation)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Philippe Le Hégaret (W3C)
Mark Little (JBoss Inc.)
Jonathan Marsh (Microsoft Corporation)
Gilbert Pilz (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (WSO2)
Prasad Yendluri (webMethods, Inc.)
Absent
Abbie Barbir (Nortel Networks)
Andreas Bjärlestam (ERICSSON)
Dave Chappell (Sonic Software)
Vikas Deolaliker (Sonoa Systems, Inc.)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Arun Gupta (Sun Microsystems, Inc.)
Yin-Leng Husband (HP)
Amelia Lewis (TIBCO Software, Inc.)
Bozhong Lin (IONA Technologies, Inc.)
Jeff Mischkinsky (Oracle Corporation)
Nilo Mitra (ERICSSON)
Eisaku Nishiyama (Hitachi, Ltd.)
David Orchard (BEA Systems, Inc.)
Alain Regnier (Ricoh Company Ltd.)
Mike Vernal (Microsoft Corporation)
Katy Warr (IBM Corporation)
Pete Wenzel (Sun Microsystems, Inc.)
Regrets
Yin-Leng Husband (HP)
David Orchard (BEA Systems, Inc.)
Katy Warr (IBM Corporation)
Chair
Bob Freund
Scribe
Francisco Curbera

Contents


Hugo: Brings up issue of leaving 2006/03 schema location

people agree

Bob: there is a proposal by Katy

Paco: just to maintain the 2005/08 schema available at that location

Hugo: that is no problem

<pauld> http://www.w3.org/2005/08/addressing/ws-addr.xsd

Hugo: There are no differences between normative and informative references in the specs; causes some confusion
... Distinction helps understand dependencies
... Phillipe went over the doc and organized normative/informative refs
... reviews informative/normative refs in document

Jonathan: Why is the WWW architecture reference normative?
... there are no MUSTs there

Hugo: Right, that is arguable I guess
... is it because the use of "recommends"?

Jonathan: it is a WWW-A 'recommends', just advice
... It is unclear what it means to conform to the WWW-A document

Hugo: goes over normative references; very few
... Let's review SOAP binding references
... 2119, IRIs, SOAP 1.1 and SOAP 1.1 ROR (should not be there), SOAP 1.2, WSDL, XSD, namespaces are normative so far

DavidH: Why do we have WSDL 2.0

Hugo: WSA may be used with WSDL

DavidH: Security is not normative?

Hugo: We don't require compliance with WSSEC

DavidD: We use the notation

Hugo: But WSSEC is not about notations, is about security mechanisms

Jonathan: proposal is splitting the references in the two specs except for the architecture and SOAP 1.1 ROR note that are moved down to informative

Hugo: we should do this for the WSDL bindign document also

Bob: Resolved, we accept Hugo's proposal as modified by moving the AoWWW and SOAP 1.1 ROR to be informative references

TomR: When is this really a REC?

Hugo: Sometime, but there is nothing more we need to do

TomR: weeks?

Hugo: yes

Bob: Next agenda issue: final incorporation of lc-comments into WSDL binding document
... we'll separate references in this document as well
... (projects reference list) which are non-normative?
... WSSEC again?
... same notational dependency

Anish: Mentions to SOAP in several places
... references are to both SOAP 1.1 and 1.2

Jonathan: there are some MUSTs as well

Anish: should we add SOAP 1.1 as well? "mU" means both

Jonathan: proposes to split Section 7 in 2 parts, along the same lines as the other docs; keep SOAP 1.1 as normative in this case

Bob: the proposal is to add a reference to SOAP 1.1 as normative, since it is not there now

Jonathan: WS-Policy is a note/member submission so it can be referenced now as informative

Bob: I'd like to agree to what we got first: we are dividing, adding SOAP 1.1, putting WSSEC as non-normative, and adding a clarification that the use of "SOAP" w/o version means both 1.1 and 1.2 versions
... approved
... Gil raises referencing WS-Policy (checks document references to policy)

Hugo: WS-Policy has been submitted but there has not been any change - it could be referenced before as well

Bob: would be non-normative (everyone agrees)

Hugo: good chance that when we republish there will be a draft out form the WG that can be referenced

Bob: how about an editorial note directing to expand the existing reference into a referenceable verion

Anish: there was a referenceable version already

Paco: but now we don't have the changing versions problem

Jonathan: and the standardization intent is now clear

TomR: the referenceable version will change as the WG start working

Anish: suggests we wait till the WG is formed and a draft is available

Bob: so it does not fall through the cracks, we record as an issue and will dispose of with our regular process
... we can create and deferr the issue, then revisit; that may be the best thing to do given the controversy, and the fact that there are no consequences on testing etc.
... issue should be reopen at the conclusion of CR phase
... approved: open issue, and refer till end of CR
... other items under lc-incorporate draft issue

Tom: Hugo's comment on removing editorial note in 3.1.1

Bob: was not acted upon, so it will be removed by editors
... agreed
... 3.2 anonymous element, first sentence. Has a reference to the SOAP module that may be a bit confusing

Hugo: suggest add clarification "see Section 3.3"; also, introducing the wsoap prefix

Bob: agreed. Anything else?
... have people checked that their lc issues are correctly incorporated in the document?

(people say yes)

Hugo: there is an uncapitalized must in Seciton 4.1. Actually two occurrences

(people agree)

(more discussion)

Bob: should the 1st must in 4.1 be capitalized?
... agreed
... 2nd use?

TonyR: would be a 'would' since is an example

Bob: agreed
... is this document ready for cr?
... group agrees that the document is completed

TonyR: do we need to vote?

Bob: only if there is dissent
... taking a break until 11:00
... next issue: decide on CR exit conditions
... requirement of 4 interop implementations was removed for theWSDL binding
... a minimun of 2 is what we prefer and would be an adequate criterion
... issue is that the doc covers two versions of WSDL so we depend on interopeable WSDL 2.0

Jonathan: currently in CR, a bit dispairing of getting implementers to step up; more optimistic now
... there is Woden with a WSDL validator and a paring WSDL into the component model
... looking at doing useful stuff with that component model representation - signatures etc.

GlenD: Axis 1 + Woden is unlikely, Axis 2 + Woden is being worked on

Dims: yes, we're working onit

Jonathan: between IBM and OS, WSO2 there will be an implementation based on OS
... Canon has an implementation as well, so we seem to have 2 implementations or the expectation of having them
... we we may meet the 2 implementation req this year, but not by the September timeframe
... many vendors work on Woden but it counts as a sinlge implementation for WSDL 2.0
... for WSA testing, there will not be enough infrastructure before the Fall

Bob: looks like the WSA chances of WSDL 2.0 testing are remote. What to do? We can go w/o WSDL 2.0 but that will not exercise many aspects of the doc
... so we could take the document and publish as a note - does not require interoperablity
... we can also seek an extension of the charter, wait to the WSDL infrastructure and get back on the rec track
... they are not excusive options

Marc: if we leave it at CR there is no need for a note

Anish: we can split the document and publish the 1.1 part as a note, leave 2.0 in CR for later

Hugo: publishing a CR means you intend to go to REC, chances are low in our timeframe

Bob: what is the best guess for having 2 WSDL 2.0 implementations?

Jonathan: end of the year
... I am using the time it took us (WSA) as a reference
... that is 6 months for a much less complex spec with more participants

Dims: Axis 2 C is also coming out and counts as a second implementation

Philippe: people are waiting to see if WSDL 2 is real, so they are not pushing implementation work

Jonathan: issues are FP and http binding
... will probably pick up slowly as IBM, WSO2 implement it and customers start asking for it to other vendors

Philippe: why not leave the document in CR and do the WSDL 1.1 testing - go to sleep and do the 2.0 testing what possible

Anish: if WSLD 2.0 CR to 2.0 is delayed we also delay the WSDL 1.1 binding

Jonathan: if we do the WSDL 1.1 testing we'll give that part of the spec a lot more stability

Anish: not suggesting going to PR w/o 2.0; two posisbilities: do 1.1 testing, no 2.0; or do both 1.1 and 2.0. In either case WSLD 1.1 will be stuck in PR

GlenD: no different with a note

Paco: the concern is the perception of stability of a document in CR

Jonathan: I don't really know how to do the split. For example, we are using the same namespace for the two WSDL versions

TomR: nice to have something refereceable and stable, for example for WS-I

Jonathan: the CR will have a dated URI and a change will require a namespace change

Marc: a CRC document is perfectly referenceable

Hugo: if we test with 1.1 as 2.0 comes along it is unlikely that major changes will be required
... we should also be very clear about what are the long term plans

Glen: we don;t really need to decide now. We should still go to CR and see what happens

Anish: problem is the perception people have of a CR document
... how do we get people the perception that we are done with the WSDL 1.1 part - a status note will not do it

Gil: no need to rush a decision now

Marc: it is actually 'us' who is going to have the problem

Philippe: it is enough if vendors implement it

Bob: net is we want to keep the spec on the rec track and that means we need to progress on what can be tested
... other option: once 1.1 is tested, we can go to REC if 2.0 seems far out, then rev the REC when 2.0 is done

<pauld> WSDL 1.1 and SOAP 1.1 as notes lead to the formation of the WS-I to manage errata etc

Bob: no need to decide now

<pauld> sees little need to rush on this specification, it's going to look very different as soon as a WS-Policy WG kicks off anyway

Bob: propose a hiatus for the month of August and target to complete 1.1 testing before then; at that point we decide how to status the document, note etc.
... we should have more information by then

Dims: can we do the test cases at the same time for 1.1 and 2.0?

Bob: good thing to do
... thinking about WS-I profiles, evidence of sucess in testing will add credibility, much more than what we 'call' the document
... call for implementations, complete all that shakes out, incorporate issues and have a doc that has been partially tested; reissue CR for 2.0 implementations
... that is what we'll try do

Jonathan: what parts will be implemented - can we get a matrix on who plans to implement what?

Bob: can we delay lunch break to 12:45 and do this?

Glen: better start early and come back

Bob: breaking till 12:45

<bob> folks, we are on lunch break, plan to be back at 12:45 or so

<bob> we resume

Bob: plan was to create the feature/support matrix to inform our test development decisions

Glen: what is the purpose of this?

Jonathan: we are not implementing parts of the spec. we'd like to know what others are intending to test so we can consider the status of different features (at risk?)

<pauld> for SOAP/Core CR testing we used the 'features' list to work out how many test cases we needed: http://www.w3.org/2002/ws/addr/testsuite/features/

<pauld> .. these were used to build the implementation report

Paco: the idea is to know what is the intent of each company

Glen: need to build a feature list

<pauld> seems likely that beyond UsingAddressing and wsaw:Action not much is of interest to many

<pauld> that still explodes to a few WSDLs

Bob: projecting a copy of the editor's draft

<pauld> x SOAP 1.1 and SOAP 1.2 x WSDL 1.1 and WSDL 2.0

<David_Illsley> pauld, I'd expect the Default Action Pattern to be important to most too

Jonathan: went over the spec for conformance statements. First the WSDL markup came up - how do we implement this?

Glen: you may be asking for a generic EPR as a result of a query - based on embedded WSDL I decide if I can talk to it

Jonathan: can you serialize an EPR with embedded WSDL would be a simple test

Glen: a good test is: presupose a WSLD with 2 services; hand an EPR that at runtime selects one of the two services and the message gets to the correct place
... decide what interface to call assuming there are two interfaces for the service, described in the embedded WSDL

(discussion of several options)

Jonathan: this eesm circular - this is metadata after all
... does testing one of may possible scenarios mean this feature is good?

Gln: yes

Gil: you want to do the minimun to show that the metadata was communicated - if you don't act on the metadata you cannot see if it was effectively communicated

DavidH: there is no MUST, what is the testable assertion?

Jonathan: conformance implies structural correctness

David: I cannot write a conformance test

<pauld> conformance section: http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#conformance

Glen: you can if you design a scenario in which this mechanism is used

DavidH: you cannot test w/o further assumptions

<pauld> scenario is effectively a reverse Turing test

Glen: you must make assumptions to test

DavidH: the reason to o this is to make sure it is implementable

Jonathan: and also that it is sufficiently interesting to make it worth keeping in the spec
... what about putting a bunch of EPRs with embedded metadata in our test documents

Glen: then what?

Marc: does not seem too useful

Bob: how many tests here, 1 or 2 (interface, and service, endpoint)?

Anish: interface narrowing is a use case: service suports many interfaces, but this EPR is used with only one of them

Paco: also validating that the interface supported by the EPR is the one the client expects

Jonathan: we can implement scenarios on WCF even if we don;t have much use for them
... we are really testing the richness of the framework to insert and extract metadata in EPRs

Glen: there is no requirement ot use these fields - if they are used you should understand what that information means

DavidH: concerned about having to build a non-tribila applicaiton to test this

Paco: validation is trivial to implement but is a very real use case

Jonathan: Section 2.2 is the same as 2.1, just embedded by value

Bob: looks at section 3.1 UsingAddressing extension
... several MUST here

Jonathan: 3 flavors: extension, policy assertion and SOAP module
... not requiring that you understand all
... want to see whether people uses WSDL extension versus SOAP module

Glen: I know what to do when I see the module in the WSDL

Jonathan: your code needs to recognize the module

Glen: behavior is already defined

Jonathan: here we have to understand the syntax

Anish: what is the policy assertion, WS-Policy?

Bob: this is the unnamed policy framework

Jonathan: then we have anonymous

Bob: Section 4: extensions ot WSDL - checking conformance section

Jonathan: falls under endpoint conformance whihc we can test
... are there any features in addition to the UsingAddressing one? Action is not really testable w/o it; embedding EPRs may be testable w/o UsingAddressing but that does not seem to add much value

Marc: need to test the algorithm for default action values

Jonathan: is this a separate feature from conformance point of view, not wrt having separate use cases
... writes possible tests/features from section 4 on board
... lists: embedded EPRs, destibation, ref. parameters, Action, default action algorithm
... Section 5, we can write tests for each MEP
... marks what MS will likely support on the table in the whiteboard

Marc: indicates what Sun is likely to support

Paco: same for IBM

Dims: considering maybe not as product but would include all in a test suite

Gil: BEA interested in supporting all features, but may not be ready by this Summer

Anish: Oracle is a 'maybe' for all features

Jonathan: output of this meeting should be the list of features and whether there is any at risk - none seems so far

Bob: should we mark these metadata related features at risk?

Paco: I would not; we have at least 2 possible implementations and they are easily tested

Bob: there is a difference in that failing to support them would then send us back to WD
... checking the charter to understand the impact of this decision

Hugo: WSDL metadata is mentioned in the charter but corresponds to WSDL 2.0 support

Jonathan: other CR criteria issues is the dependency other groups take on this specifications

Bob: current version of W3C process document: CR exit does not require an implementation, but it is up to the director to approve if a convincing argument is made
... since our charter sets no specific requirements either, I suggest we go ahead with the full feature set regardless of the questions
... on the way some of them are tested

Paco: I would not say that we don't know how to test

Bob: we have too many options

Anish: it is easy to define a minimal bar on which all agree
... there is a minimal set and there are more sophisticated testing methods; the discussion is what of those tests to select
... the minimal is being able to include and parse the metadata in the EPR

Gil: but that does not test anything

Bob: displays the summary table; metadata features have 3 possible implementations; soap module none so far; rest have 5
... we will revisit the table and add a second column after the July tests
... we have the table and a target timeframe. We now need to figure the test cases, test harness etc.

Jonathan: an exit criteria is the existence of a test suite

Bob: breaking for 15 minutes
... back in business
... so we mark no feature to be at risk
... discuss progression to CR. We already agreed on the document we can move ahead, Marc will commit changes tonight
... anything else we need to doto the document?
... what is the end date for CR?

Hugo: it is to state a date before which we don't go out of CR

Bob: how it relates to the testing calendar?

Hugo: a little before the end of the testing period

Bob: checks calendar, around end of June - how about June 30 or July 7?

Paco: let's do June 30.

Bob: Since a call on July 3 would be difficult, there is essentially no loss in taking July 7 instead
... July 7 will then be the end of CR interval
... Minutes of the last minutes are approved
... back to the table - how to generate test cases for the features on the table - let's start with Section 4, should be easier

Jonathan: will we have a test assertions documents so tests can be generated automatically?
... methodology: get a log out of the test case run, check the log against assertion document

Glen: adding any kind of metadata requires someone to consume the metadata

Jonathan: assume there is a WSDL with different Actions, you test that the WSDL is read and the right Actions go into the right messages

Bob: projecting assertion document from prior test suite
... we extracted the MUSTs, etc into a set of explicit assertions

Jonathan: we had soem XPath testable expressions too

Bob: not in this document, possibly somewhere else
... the assertions document looks very good. What next?

Jonathan: we had a set of XPaths, MEPs, etc that state specific properties that drive form the assertions and can be tested agains the run logs

Bob: opens testcases.xml, shows specific document names, MEPs, XPaths to check

Hugo: there is testcases.html also

(checking the file...)

Paul: explains how the file was built, answers questions, provides details

Glen: you can do al lwith one WSDL; question is whether you need to exchnage messages also

<pauld> first round was driven by 'features' higher level than 'assertions' (generated from MUST/SHOULD statements)

<pauld> goal was to test the spec, not implementations

Paco: Do you check assertions against both the WSDL and the messages? they are supposed to be ocrrelated.

Jonathan: we already truted people to do the right thing we can do that now again

<pauld> I'm not proposing we don't exchange messages, just exploring methods of reducing the number of WSDLs needed to test, which is the expensive bit

Jonathan: the WSDL will be static so the only error is if people mistype the Actions, etc.

Glen: we can put forward a few tests and see of we can have a single WSDL for all. We may be able to have a single WSLD document but you need several services so we may as well have several documents

Paco: how we decide feature/test granularity -affects the feature at risk decision

Jonathan: it also helsp us partition the job

Bob: regarding the structure, not all are equally tempered from the point of view of working the details and the granularity
... can we take the next step from the first set we have identified in the implementation table
... the goal (as Paul said) is to validate the spec, not the implementations

Jonathan: we care less about the edge cases
... once we have a framework hings accelerate very much, it gets easy to extend and add new tests

Paul: a feature list does not say all test we need, just which ones we need at least; more can be added
... that detrmines if a we pass CR

Bob: can we move this first list to the assertion level? have the next level ready tomorrow or the next call

Glen: we should do 2-3 soup-to-nut test cases

Jonathan: we can split into subroups that take different features and get it refined

Bob: to do tomorrow: break down the feature list to one more level of detail, annotated with what the spec requires we test. Define what kind of stress to put on the infrastructure
... goal is to answer those questions tomorrow. Some of it is simple, but the soup to nuts test structure is the harder, we should focus on that first thing tomorrow

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/05/09 20:33:51 $