See also: IRC log
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