See also: IRC log
<jkaputin> Look's like I'm showing as Jeremy Hughes today instead of Roland Merick
<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?
scribe gpilz
<scribe> scribe: gpilz
UNKNOWN_SPEAKER: approved
Review of Action items [.1].
[Interop]
? 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
[WG]
? 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
appears.
? 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 (?))
http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR118
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!
Johnathan: 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.
Resolved: Remove assertion markup from Endpoint-0065, InterfaceFault-0032, InterfaceOperation--0035
http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR123
Jonathan: This is one of Youenn's
Youenn: (reviews the issue)
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.
???: Didn't Arthur fixed this already?
Jonathan: Could be. The end result is the same.
<plh> a/Amy/Amy/
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
http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR128
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