WS Description WG telcon

18 Jan 2007

See also: IRC log


Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Youenn Fablet, Canon
Amelia Lewis, TIBCO
Philippe Le Hegaret, W3C
Jonathan Marsh, Co-chair/WSO2
Jean-Jacques Moreau, Canon
Gilbert Pilz, BEA Systems
Tony Rogers, Co-chair/Computer Associates
John Kaputin, IBM (for Arthur)
Charlton Baretto, Adobe Systems
Paul Downey, British Telecommunications
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universitšt Innsbruck, Austria
Arthur Ryman, IBM


Implementer's call

<jkaputin> Look's like I'm showing as Jeremy Hughes today instead of Roland Merick

<plh2> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results-messages/MessageTest-1G/log-MessageTest1G-canon-canon-results.html#message1

<Jonathan> <test id="MessageTest-6G" binding="SOAP12">

<Jonathan> <log client="wso2" service="wso2" id="MessageTeest-6G-wso2-wso2"

<Jonathan> >MessageTest-6G/log-MessageTest6G-wso2-wso2-output.xml</log>

<Jonathan> </test>

<Jonathan> <log client="wso2" service="wso2" id="ModuleComposition-1G-wso2-wso2"

<Jonathan> >ModuleComposition-1G/log-ModuleComposition1G-wso2-wso2-output.xml</log>

<Jonathan> ACTION: Jonathan to factor multipart out of MessageTest-2G [recorded in http://www.w3.org/2007/01/18-ws-desc-minutes.html#action01]

<plh> /home/plehegar/dev/2002/ws/desc/test-suite/results-messages/build.xml:195: input file /home/plehegar/dev/2002/ws/desc/test-suite/documents/good/MessageTest-6G/SOAPservice.wsdl does not exist

<plh> hum, did you forget to add this file in cvs Jonathan?

<plh> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results-messages/Message-tests-results.html

scribe gpilz

<scribe> scribe: gpilz



action items

Review of Action items [.1].

?         2006-11-30: [interop] John Kaputin to create a test case 
                      with "required=false". 
?         2006-12-14: [interop] Jonathan to fix transferCodings - 
                      add control group

?         2006-09-21: Jonathan to check periodically that SPARQL has 
                      added schemaLocation.
?         2006-12-14: plh to come up with a more detailed proposal for 
                      CR112 if possible
DONE      2007-01-04: Jonathan to make sure parameters are added to the 
                      URI in the HTTP binding even when no whttp:location 
?         2007-01-04: Paul to report back on which test cases in the 
                      WSDL test suite fail the basic patterns, with
                      suggestions on how to address the issues.
?         2007-01-04: Jonathan to analyze CR117 further.
DONE [.3, .4, .5] 2007-01-11: Jonathan to send WS-Policy comments to the 
                      WS-Policy WG
?         2007-01-11: Jean-Jacques to provide more analysis on how 
                      difficult it would be deal with a Policy that 
                      only contains an MTOM policy assertion 
DONE [.6] 2007-01-11: Philippe to propose a grammar for http:location

Current Editorial Action Items

Note: Editorial AIs associated with LC issues recorded at [.2].

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html
[.3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4211
[.4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4211
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0105.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0088.html

UNKNOWN_SPEAKER: Phillipe posted his proposed grammar


UNKNOWN_SPEAKER: Mostly defered items


Phillipe has proposed a grammar

<plh> httpLocation ::= CharData? (( openBrace | closeBrace | elementName ) CharData?)*

<plh> CharData ::= [^{}]*

<plh> openBrace ::= '{{'

<plh> closeBrace ::= '}}'

<plh> elementName ::= '{' NCName '}'

John Kaputin: Grammar seems ok to me.

Jonathan: Everybody ok with this?

Resolution: Close CR130 with this proposal (mod change proposed by Jonathan and reference to XML spec (?))



Jonathan: (reviews issue)

Phillipe: Is the schema normative?

Jonathan: Yes.

Roberto: (missed his point)

John: If you're a WSDL 2.0 implementation and you provide an API that allows you to build a component model at some point you need to validate that model.
... If the only way you can do this is via schema validation, that means you need to generate the infoset then run it through a validating parser.

Roberto: agrees

Phillipe: Also, removing these two assertions basically remove them from peoples understanding. The assertions exist in the schema but that's the only place you would see them.

John: Not really sufficient to simply describe the assertions in the schema.

Jonathan: Are you concluding that the endpoints are not constrained to be unique?

John: Its not sufficient to express this constraint solely in the schema.

Jonathan: The assertion failure will never be reported by schema validation alone since the XML doc will fail during validation!

Jonathan: We don't have all the assertions that are implemented by the schema reflected in the spec. We should be consistent and remove the first assertion.

Phillipe: We should be consistent.
... If there is a general rule, we should state what it is.

John: I agree that we should be consistent.
... If there is a WSDL 2.0 API that allows you to build up the component model programatically, is there a way to validate w/out serializing then parsing?
... Not if you take these assertions out.
... The idea of having assertions implemented via schema works fine if you always start from a WSDL 2.0 document.
... Suppose, instead, you start with some WSDL 2.0 authoring tool. You build up the descritpion component, by component. What happens when you want to validate
... your component model. If you remove these assertions then it is possible (likely) that these constraints will be missed unless the ONLY way of validating
... is to serialize the component model as a WSDL 2.0 document and run it through a validating parser.

Jonathan: This is an artifact of the way we test WSDL 2.0 assertions. We always start with a WSDL 2.0 document then run it through a parser. These assertions can never be
... violated using that process since the document will fail schema validation before you ever get to checking assertions.

John: If you rely on schema validation to report errors, the same error may be reported in different ways depending upon what parser you are using.

Jonathan: If we remove the asssertion markup from these statements . . .

John: There are others as well . .

Jonathan: If we continue to write test cases we will find other assertions for which we cannot write test cases.
... We could also simply review the specs and try to find more.

<alewis> is our schema normative?

John: How do you write test cases to violate the rules in the schema if some/most of those rules aren't expressed as assertions?

Jonathan: We don't. All of our test cases start from well-formed, schema-valid documents.

John: Should we raise an issue to read the spec looking for assertions that violate schema?

Jonathan: Yes, but we need to find a volunteer (outlines scope of work)

John: I'm not sure if the green tests in the coverage report can be ignored.

Jonathan: The green tests mean that Lawerence was able to write a WSDL that passed schema validation and violated the assertion.

John: But Woden doesn't necessarily stop when schema validation fails.

Jonathan: But Lawernce doesn't check in the test case if it fails schema validation.

John: Ah. So that leaves some 60 assertions to check.

Jonathan: I suggest we fix the ones we know about and fix others as we find them.
... We just need to remove the "assertion" markup.
... Don't think it would be the end of the world if we remove the assertion markup.

John: Endpoint-0065, InterfaceFault-0032, InterfaceOperation--0035
... What about Interface--0030?

Jonathan: No this isn't because its refering to an interface from another document.
... Both documents could be schema-valid but combined they would validate the assertion.

Resolution: Remove assertion markup from Endpoint-0065, InterfaceFault-0032, InterfaceOperation--0035



Jonathan: This is one of Youenn's

Youenn: (reviews the issue)

<plh> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#_http_binding_default_rule_method

John: If safety is not engaged, couldn't it be GET or POST?

Youenn: In the HTTP binding there are rules to tell you whether to use GET or POST.
... The safety extension is pretty cheap. We should state that generally, when you engage the HTTP binding you should also enage the safety extension.
... Woden and Canon both implement both of these so there isn't a problem.

Jonathan: So we just have a statement when we introduce the HTTP binding saying that supporting the safety extension is a pre-condition to supporting the HTTP binding?

Youenn: Yes.

Yoenn: When we use the SOAP binding with HTTP extensions, what is the effect (if any) on the safety extension?
... Do we also mandate support of the safety extension?

Jonathan: I would say no because the HTTP method property is not a property of the SOAP binding.

John: (clarifies)

Phillipe: What happens in the case of the SOAP response MEP when SOAP is using HTTP?

Jonathan: The SOAP response MEP, when bound to HTTP, must use a GET.

Resolution: Close CR123 by adopting Youenn's proposal.

John: Was the proposal we just adopted about mandating the use of safety if binding type is HTTP? It looks like its already mandatory?

Jonathan: Right now its an extension and all extensions are optional.


Jonathan: This one is already done.

Resolution: Close with editorial actions that have already occured.


Jonathan: This one looks editorial. The pattern attribute is always required. We need to fix the misleading "defaulting" language.

Amy: Didn't Arthur fix this already?

Jonathan: Could be. The end result is the same.

John: That means taking out the "otherwise" bit in the ???

Amy: The idea was that we weren't going to require people to explicity put the attribute in.

<JonathanMarsh> Proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0038.html

<JonathanMarsh> + add ? to the pseudo-syntax.

<JonathanMarsh> + change the schema

<JonathanMarsh> + change the interchange format

Resolution: Close CR125 by adopting Amy's proposal mod the above changes.


Jonathan: (reviews issue)

John: Do we have any other statements like this which talk about the document as a whole?

Jonathan: I think we do.

<TonyR> RESOLUTION: close CR126 with the proposal in the issue

Jonathan: For example Schema-0018


Youenn: (reviews issue)

Jonathan: Related to CR134. They're pretty much the same thing. I have a proposal for CR134.

John: Could you review CR134?

Jonathan: (reviews CR134)

John: So the proposal is to add advice to the primer?

Jonathan: Yes. We've discussed this at length.
... Is this a sufficient proposal for CR127?

Youenn: Yes. I also think that it might be good if Woden was able to warn people when such situations may occur.

Jonathan: That would be useful. You might want to consider that as a product feature.

John: You could turn this into a warning assertion.

Jonathan: We've had sufficient debate around adding normative text around operation dispatch. We don't want to go there . . .
... This proposal matches the behavior you get "out of the box" with the HTTP binding

RESOLUTION: Close issues CR127 and CR134 with Jonthan's proposal for CR134



Roberto: The last sentence in the issue doesn't seem to relate to the previous exposition.

John: The implied question is how interface extension works.

Jonathan: Arthur already replied to Cindy.
... There are really two questions; does "extension" including things extended by the thing you extended? The other question is about the use
... multiple extends attribute.

John: We could fix the first by changing the wording to "extends directly or indirectly"

<jkaputin> The set of operations available in an interface includes all the operations

<jkaputin> defined by the interfaces it extends directly or indirectly, together with any operations it directly

<jkaputin> defines

<jkaputin> The set of operations available in an interface includes all the operations

<jkaputin> defined by the interfaces it extends directly or indirectly, together with any operations it directly

<jkaputin> defines

RESOLUTION: Close CR128 with above changes

<jkaputin> clarify visibility of schema components and ensure the spec is clear

Summary of Action Items

[NEW] ACTION: Jonathan to factor multipart out of MessageTest-2G [recorded in http://www.w3.org/2007/01/18-ws-desc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/01/18 17:42:23 $