WSDL Telecon
9 Sep 2004


See also: IRC log


David Booth, W3C
Allen Brookes, Rogue Wave Software
Helen Chen, Agfa-Gevaert N. V.
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Paul Downey , British Telecommunications
Hugo Haas, W3C
Tom Jordahl, Macromedia
Kevin Canyang Liu, SAP
Jonathan Marsh, Chair (Microsoft)
Jeff Mischkinsky, Oracle
Dale Moberg, Cyclone Commerce
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Bijan Parsia, University of Maryland MIND Lab
Arthur Ryman, IBM
William Vambenepe, Hewlett-Packard
Umit Yalcinalp, Oracle
Prasad Yendluri, webMethods, Inc.
Anish Karmarkar, Oracle
Erik Ackerman, Lexmark
Jacek Kopecky, DERI
Amelia Lewis, TIBCO
Peter Madziak, Agfa-Gevaert N. V.
Asir Vedamuthu, webMethods
J. Marsh
Bijan Parsia


Minutes from last week approved

Action Item review

Schema task force will likely start up after next F2F

Action Item review

Closed Anish's action itiems


Closed jmarsh's editorial on requirements doc

Might want to officially republish requriements

Speak up if you think it's important to do so

GlenD doing his action as we meet

Arthur's action closed, put on F2F agenda

F2F agenda

RDF mapping: an hour

Primer: mostly looking at examples; an hour or two
... figure out plan...can we get out a new working draft

jmarsh: desire to get new Primer draft out before end of LC

SOAP 1.1 binding: Asir worked on it, but won't be at F2F

Media Type Desc Note: Draft to LC by F2F (need syched vote from XMLP WG), hour or two

Last Call Issues will dominate

Arthur: QA issues, perhaps?

Marsh: I have a necessary action item precursor, should I complete it?

Arthur: yes, also Paul's coverage tool

Paul: distinction between test pack and CR requirements

Marsh: We get to define CR requirements as we want. Nice to refer to test pack

bijan: owl refered to test suite but didn't CR require anyone to cover all of them (e.g., there were extra credit ones, etc.); point being, make your test suite as wide as you like/can; make CR requirements narrower; they can diverge

Last Call Issues

Marsh: Added some new issues and split up some old ones
... LC9 and LC10
... Another comment from a friend of Roberto (FOR). Should I add it as an issue?
... About infault and outfault

Roberto: Yes, but we should ask for clarification

Marsh: Ok, will monitor thread but not yet enter it as an issue

Agenda item 7 (media type description)

Marsh: What's the status?

Umit: It's been resolved

Marsh: Yes, just trying to loop back to raiser

<Marsh> ACTION: Check with MarkN on 198

Umit: What's the goal for us re: end of LC?

Marsh: XMLP has even more of a dependancy, so we should try to get it done as soon as possible, e.g., in F2F
... I.e., move it to LC, but we won't be able to finish it before end of our other LC
... but it's a note, so no CR so likely done before other things go Rec
... Shouldn't delay anyone's CR implementation, so we really want it pubbed before/at CR
... XMLP has incentive to finish this rapidly

Agenda 8, Issue LC 7

Marsh: Raise by QA, mostly typos
... any volunteers to analyze before handing over to editors?

TomJ: seems all editorial to me

someone else agreed

RESOLVED: LC7 referred to edtiors

Marsh: Wanted to do this for LC10, but Hugo pointed out problem

Hugo: methodDefault vs. defaultMethod, seems like a mere typo, but it seems to reflect a deeper inconsistency overall
... I prefer fooDefualt to defaultFoo. So can we regularize this throughout the spec

Marsh: Schema uses fooDefault
... So we have defaultTransferCodingand hugo proposes to reverse

TomJ: sounds reasonable
... Consistency seems virtuous even when possibly ugly

Marsh: Proposal on the table: Change defaultTransferCoding to transferCodingDefault and fix all introduced typos
... Any objections to fooDefault?
... No objections

Kevin: What's the leading letter case

Marsh: start with lower case

<Marsh> New LC11: rename transferCodingDefault

RESOLVED: LC10 refered to editors (see LC11)

Agenda 10, LC5d-etc.

Marsh: should we give names to processer classes

DBooth: sure, why not

Marsh: So when making a conformance claim about products, you'd have a cute name for it

DBooth: Not strictly necessary since the text defines a conformant processor as one on the requester side, but it's still a reasonable move

Marsh: you happy with the proposal, "WSDL2.0 Request Processor"?

DBooth: I'd go with "Requesting Processor" (not WSDL or WSDL version specific) oh, yes it is, so keep the WSDL

Bijan: request or requesting

DBooth: "Requesting"
... oh, it sounds like its a processer that's *requesting* WDSL

Umit: Indeed, very unclear.

DBooth: Maybe we should further clarify by pointing to something that has caused the scribe to totally lose it

Marsh: Why are we restricting which processors we talk about?

DBooth: the reason for the distinction between provider and requesting is becasue the requirements are different, e.g., optional features must be supported by the server

Marsh: but I don't see why we need two classes. Take the example of HTML

DBooth: We're talking about the *processor* not the document

Marsh: well, we have user-agents

DBooth: but isn't the conformance of a browser different from that of a server

Marsh: but HTML never talks about servers

Umit: But HTML is document conformance, so user-agent conformance reduces

Marsh: Rephrase, "When a WSDL document is processed by software trying to use a web service, it must..." [HUGE paraphrase]

DBooth: "When a WSDL document is processed by an entity trying to *use* a web service, these rules apply" And similarly for a entity trying to provide the web service

Marsh: only need the first as we have no other rules

DBooth: not explicitly, but take the case of optional features on the server

Marsh: but that's just an issue of whether your description is *correct* (i.e,. correctly describes your web service), not a conformance issue

DBooth: sure

Marsh: Two issues, we need to describe the conformance class, then we must drop the word "class"

Scribe not clear he got that right

DBooth seeks clarification

Marsh tweaks wording

DBooth: Thus we remove the term "conforming wsdl processor"?

Marsh: No, just "class"

DBooth assents

Marsh: do we agree that this can be edtiorial rather than requiring defining a class of processor?

DBooth: yes

Marsh: resolve with suggested wording from Marsh or DBooth for editorial action

<scribe> ACTION: DBooth to remove the word "class" from 8.3

Marsh: moving to the "legal wsdl document" issue
... We have a document conformance section which talks about a conforment element. So we define a conformant definitions information element, but not a conformant *document*
... we could resolve by saying a conformant wsdl doc is one whose root is a conformant definitions element

DBooth: Can we just change "legal" to "conformant"?

Marsh: not really, since the document issue. Bit silly, but worth cleaning
... LC5e resolve by replacing legal wsdl doc with conformant wsdl doc, and define conformant doc as above
... Hmm. Potential problems from 4th bullet in 8.3
... Change 8.3 to talk about conformant element, would moot the need for document def

Seems to be some serialization issues

JeffM: let's avoid those

DBooth: Still useful to define wsdl document, convenient and nice

Marsh: Not define the document as an XML document with a certain root, but as a definitions element and all its descendents
... Strange use of the term "document"

Umit: Interacts with wsdl:location?

Marsh: who knows!

Umit: will location let you get a WSDL definitions embedded in another document?

Marsh: ok, it's in seciton 7 and that refers to documents *or* fragmetns etc.
... So, its a hint to a wsdl document defining wsdl components

DBooth: so, on the new def of document, we'd fit in with fragments etc.

Marsh: Seems handy
... Proposed resolution to add a def of WSDL Document as a WSDL definitions element and its descendents and we may want to put it in the notational conventions section (1.3) and then simplify 8.1 accordingly
... and we want to change "legal" to "conforming" wsdl document

RESOLVED: LC 5e add a def of WSDL Document as a WSDL definitions element and its descendents and we may want to put it in the notational conventions section (1.3) and then simplify 8.1 accordingly and we want to change "legal" to "conforming" wsdl document

Marsh: LC5f, fault vs. wsdl error/failure

Dbooth: We should be consistent and clear

Marsh: former is runtime, latter is design time

DBooth: Section 8.3, change bullet 2 from fault to fail

Roberto: See also bullet 5

DBooth: how about addressing error handling in a processor

Marsh: what does that mean? We say immediately cease processing

Umit: It's about reporting to the user of the processor

Arthur: should report the test assertion that was violated in a standard way

Marsh: I don't think we need to get into the exact text of error message

Arthur: More like Error numbers

Marsh: Providing that is good, but must we require that of processor?

Arthur: *should*
... what does schema does?

Umit: Schema processors get in trouble since error reporting isn't standardizes

DaveO: There was a list that schema provides but processors tend to just fail

Roberto: Distinction between catastrophic error and recoverable error

Marsh: XML interesting example: strong failure, but many processors will finish processing and let you correct a bunch at once

Roberto: may continue processing *to search for further errors*

some minor discussion

<Roberto> http://www.w3.org/TR/REC-xml/#sec-terminology

Roberto: at top of that link you have def of error and fatal error

Umit: What *is* a fatal vs. nonfatal error? There is no nonfatal case!

DaveO: You can make the same case for XML or Schema

Roberto: Say you were processing an interface and found an error *in* an operation, you might want to continue. But say an error in a required extention, you should die

DaveO: Roberto are you proposing we go the XML way?

Roberto: yes! And make things clearer

DaveO: You think WSDL just inherited terminology (inappropriately) from SOAP?

Roberto: Yes

DaveO: You're proposing we adopt "error" and "fatal error"?

Roberto: sure

Umit: I thought we had certain error avoiding situations already?

Discussion about conformant document vs. conformant processor

DBooth: We handle some of this by saying a processor can process a subset of the document. And the rules are all prefaced "if this thing is processed, then"

Umit: Yes, but this goes farther and says "Even if you process it, you can ignore it"

DBooth: I don't think we have any non-fatal errors defined in the spec yet

Marsh: We had lots of discussion about defining document validity, but we tried to avoid defining processor conformance. We had to in order to deal with required extension, but do we need to go further?

DBooth: Roberto proposes adopting XML terminology defining two classes of error, but I think we, in fact, only have members of one class

Roberto: But I think we overdeclared some of our current errors and we could redeclare them more sensibly

Umit: Roberto are you suggesting we clarify the ignorable bits?

Roberto: no. we still have ignorable subtrees, but we clarify for each error whether it is fatal or not. And if fatal there are stronger constraints on a processor

DaveO: seems quite sensible. Schema didn't anticipate other people making use of their specs. Someone might want to use WSDL the way we want to use Schema and this distinction would help.

DBooth: Any examples of non-fatal error

Umit: The operation example from Roberto is not a good example

Marsh: We could tentative adopt error/fatal error and assign an action for someone to go through and try to categorize our existing errors

<scribe> ACTION: for Roberto to classify our errors as fatal or non fatal

Discussion of error in terms of document conformance

Actually, scribe evidently got lost

Marsh: XML has the same problem, esp. on document conformance vs. processor conformance

DBooth: To clarify, the error classification is for just processor section, or throughout the document

Roberto: Conformance is binary. But the distinction might help with reporting the kind of non conformance (or reason for such?)

LC 5g

Marsh: just remove the word "agree"

Much agreement

Marsh: what do we mean by "fully abide"? I.e., in order to claim WSDL conformance must I also investigate my conformance of all the extension I support?

DBooth: yes

Marsh: proposes some clearer text
... are there issues, e.g., with granularity of conformance

DBooth: You don't conform to the fine grained feature then you don't conform to WSDL

Summary of Action Items

[NEW] ACTION: Check with MarkN on 198
[NEW] ACTION: DBooth to remove the word "class" from 8.3
[NEW] ACTION: for Roberto to classify our errors as fatal or non fatal

Minutes formatted by David Booth's scribe.perl 1.90 (CVS log)
with some hand editing of both the source log and the HTML by the scribe $Date: 2004/08/10 15:51:28 $