See also: IRC log
Last week's minutes approved.
(Discussions of Jan F2F timing; JMarsh still working on trying to co-locate with the Addressing WG.)
dbooth has a conflict Jan 12; Asir in Brisbane for XML mtgs the week of Jan 17; GlenD cannot do the week of Jan 24.
JMarsh: 4 new issues this week, including Amy's issue of
importing WSDL 1.1, and Anne's issue of one interface per service.
... Media type description LC has been published.
... Need to decide how we wish to process issues on that document.
<Roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0008.html
(Looking at Roberto's list of errors, to see if they are classified acceptably.)
Roberto: For the <definitions> element to be valid, the entire document must be valid. Therefore if it is processed, the entire document must be validated.
DaveO: Should we use some concept of partial validity, as in XML Schema?
Arthur: In permitting portions of a WSDL document to be
invalid, what is the objective? To make it easier on authors?
... Why not say that the result is undefined if the document is
invalid?
Roberto: That would be different than what we have now.
dbooth: We've been trying to straddle two camps.
Arthur: What's the benefit of specifying the behavior of invalid input?
dbooth: It leads to interop problems if processors are lax (silently permitting invalid input), because the author may not realize that the documen is invalid. Then it works on some processors and not on others.
Roberto: What if a processor encounters a part of the
document with a required extension that it doesn't understand?
... This notion of partial processing is hard to justify if you have a
global validity requirement.
... The objective is to permit a processor to ignore parts of the
document that it doesn't need.
... I also think it's important to call out as errors: references to
type system components that don't exist.
... You can do a lot of useful things even without the concrete
definition of an element.
... I think it's useful to permit some processor recovery when the
message type reference is bad, for example treating it as xs:any.
<pauld> i thought we agreed in Cannes not to define classifications or compliance of 'processors' but to just concentrate on if the document is valid or not?
JMarsh: Anyone want to call all errors fatal? (No response)
Asir: What is the point of listing broken QName references here and not in the fatal list?
Roberto: Fatal list wins.
Asir: Is there any other place where I would use a qname
to reference components?
... Same comment applies to "(3.1.3) having an "element" attribute
refer to a global type definition"
Roberto: I thought as part of Z notation we were changing the way we refer to components.
dbooth: I am sympathetic to Arthur's suggestion that we say the result is undefined if the document is invalid, but we could also say a processor SHOULD report any error that it discovers. Perhaps this would allow latitude needed, but also encourage error reporting.
Arthur: There were two kinds of relation in a component: one containing another; one referring to another. But the spec was changed to view all collections as references, and this complicated the Z notation, because I needed to add an implicit ID on each component.
PaulD: A long time back we discussed the distinction between doc validity and processor conformance. We agreed to focus on whether the document is valid or not. Saying "a processor SHOULD report errors" is not helpful if it's embedded in a cell phone.
Asir: As it stands today I see three entries in the non-fatal errors list, and everything is a component, these three ARE fatal errors.
Roberto: Like DBooth, I like the GIGO rule, but there are some details hidden that we still need to discuss. Need to be sure we don't require validation. We should say the processor SHOULD report an error if it encounters one, but at present we say in some places where a processor MUST fail, so we still need to clarify the difference between different kinds of errors.
JMarsh: Our original motivation for defining a WSDL processor was to clarify the meaning of wsdl:required.
dbooth: I think we can still define the meaning of wsdl:required without defining a WSDL processor.
Arthur: My main concern was us trying to define "garbage-in, non-garbage out".
<pauld> thinks it might be useful to have a notion of a 'validating wsdl processor' rather than just 'processor' which SHOULD report errors. anyone else can go GIGO, or follow Postel's law if they're sent an invalid *document*
JMarsh: Imagine a non-well-formed document. (Well-formed,
but an extra char at the end.) Now imagine a WSDL processor that
streams the input and only looks at what it needs. That wouldn't
conform if we require detection of non-well-formedness errors.
... So it's hard to draw the line on what a minimal processor must do.
PaulD: That seems ok to me. Might want to introduce the concept of a validating WSDL processor.
JMarsh: Could say "whatever processing you do, you should detect and report as many errors as you can".
Roberto: I don't see how we can define the meaning of
wsdl:required without defining a WSDL processor.
... There are also processor conformance requirements: must accept XML
Schema, etc.
... Right now I see only two things that need the WSDL processor
definition: 1. you must fault if you encounter a required ext that you
don't understand; and 2. a wsdl:include with a non-dereferenceable URI
Arthur: Need to define the mustUnderstand concept.
<pauld> processors "should detect and report as many errors as you can" sounds fine, if not a little "motherhood and apple pie"
dbooth: I think the spec may already define the meaning of wsdl:required as an extension that MAY change the semantics of the WSDL document. Therefore, if a processor doesn't recognize one, then the result is undefined.
<Arthur> less is better so if David can avoid the need for a processing model, I'm all for that
JMarsh: DBooth and Roberto are tending toward a model based on document conformance, rather than defining a conformant processor. Is this direction promising? (Some think so.)
<scribe> ACTION: dbooth to define the meaning of wsdl:required in terms of the document, rather than processor behavior.
<Roberto> processor requirements that are independent of a processing model are ok, e.g. MUST support XML Schema
dbooth: So it sounds like we're going in the direction of basing our error model on document validity, and GIGO. But we could still have some additional processor conformance requirements if we wish, such as a general "SHOULD report errors it sees" and some specific requirements, such as MUST support XML Schema.
http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0061.html
Any objections to accepting DaveO's proposed new text? Which is:
[[
* Mechanisms other than setting the serialization properties MAY
modify the serialization format of the instance data
<http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#instance_data#in
stance_data> corresponding to the message. An example of such
modification is the WSDL SOAP Binding HTTP URI Serialization rules
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#soap-defaults.
This binding specifies that the SOAP-Response Message Exchange Pattern
<http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapresmep>
([SOAP 1.2 Part 2: Adjuncts
<http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#SOAP12-PART2#SOA
P12-PART2> ], Section 6.3) only supports input message serialization as
application/x-www-form-urlencoded. Other examples of such mechanisms
are other message exchange patterns or bindings.
]]
(No objections)
dbooth: This also addresses an issue that I raised, of the old text being unclear about how the serialization format might be changed.
[Adjourned]