See also: IRC log
Minutes from last week approved
Action Item review
Schema task force will likely start up after next F2F
Closed Anish's action itiems
(editorial)
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
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
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
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)
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