See also: IRC log
<scribe> scribe:Paco
Hugo: Brings up issue of leaving 2006/03 schema location
people agree
Bob: there is a proposal by Katy
Paco: just ot 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: no differences between
normative and informative references in the specs; causes some
confusion
... Distinction hekps understand dependencies
... Phillipe went over the doc and organized
normative/informative refs
... reviews informative/nirmative 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: propose 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 nirmative, 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 in 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; thta 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 reomoving 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?
... has 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?
... group agrees that the document is completed
TonyR: do we need to vote?
Bob: only if there is
dissent
... taking a break until 11
... next issue: decide CR exit conditions
... requirement of 4 interop implementations was removed to
WSDL 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
deapairing of getting implementers to step up; more optimistic
now
... there is Woden with a WSDL validator and a paring WSDL into
the component model
... lookint 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 cass 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 oimplement 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
Geln: 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
Geln: 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 test 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
Bob: should we marke 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 imple; 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 no essentially 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 one morelevel 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 is simple,
but the soup to nuts test structure is the harder, we should
focus on that first thing tomorrow
<bob> rrsagent make logs public
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/porposal/proposal/ Succeeded: s/Turing/reverse Turing/ Found Scribe: Paco Inferring ScribeNick: Paco WARNING: No "Topic:" lines found. Default Present: Prasad_Yendluri, Mark_Little, [IBMCambridge], Paul_Downey, David_Illsley, prasad Present: Prasad_Yendluri Mark_Little [IBMCambridge] Paul_Downey David_Illsley prasad WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006May/0001.html Got date from IRC log name: 3 May 2006 Guessing minutes URL: http://www.w3.org/2006/05/03-ws-addr-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]