See also: IRC log
<Roberto> Scribe: Roberto
Agenda bashing ongoing.
Discussion on schedule.
Work on last call issues until November.
Then revisit the issues for which we got minority opinions.
Then go to CR.
Anish: one issue was not incorporated, namely the q parameter
... that's issue 245
<anish> http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0023.html
JM: there's also a thread on 252 started by Umit
consensus not to reopen 252 based on Umit's mail
JM: new issue: http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0016.html
Anish: we say what @contentType means, but that does not provide much value to applications
... applications are free to ignore it
... tools cannot use the expected media type value and generate special code
... proposal is to remove the second statement "the annotation should be considered only as a hint"
consensus to remove that sentence
JM: new issue: optionality of contentType attribute http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0019.html
Glen: issue says "if there is optionality in the description, we should mandate that at runtime the content type is specified"
Sanjiva: it's fine as it is, the spec says that the two values should be consistent
Anish: optionality wasn't really discussed by this group until now
Tom: the two attributes are linked, so we should list the rules
Sanjiva: @contentType wins, it tells you what the data is
... the spec says that, the value of @contentType must be in the range listed in the description
Anish: analogy between expectedMediaType and HTTP Accept header
HH: service providers and consumers have different capabilities; do we address that?
Sanjiva: we don't
Tom: the specification should address these three cases
Glen: lack of media type (or use of a wildcard) in the schema says that there needs to be some other way of figuring out what the actual data type is
JM: do we need to require that implementations signal the same errors?
Tom: proposes to require contentType when expectedMediaType has a wildcard
JM: this would force a messaging stack to reject all descriptions that use expectedMediaType if it doesn't support contentType
... concern is that @expectedMediaType is very useful in many contexts, so we shouldn't tie it to Web services
... example: XML Query
<anish> how about saying that if the expectedMediaType contains a wild card or a list then the instance document SHOULD contain some way for the receiver to figure out the media type of the binary data. contentType attribute being one such mechanism.
Kevin: the schema author could make @contentType required
<dbooth> Proposal on the table: "When expectedMediaType is used and has a wild card or list, you SHOULD write your message schema to require a contentType."
consensus on adopting this proposal
DBooth: who should register the media types?
JM: the WG, but no specific person
<dbooth> Info on how to register the media type: http://www.w3.org/2002/06/registering-mediatype
JM: call for volunteers to manage the registration of our media type
Arthur: which extension should we use? .wsdl? .wsdl20?
DBooth volunteers
JM: no other media type issues
... do the edits tonight, then have everybody review the document tomorrow and discuss any new issues on Thursday
<anish> html media type rfc -- http://www.ietf.org/rfc/rfc2854.txt
<sanjiva> +1 for .wsd and .wsdl because our WG is called WS-D too :(
coffee break until 11am
<anish> xop media-type -- http://w3c.org/TR/2004/CR-xop10-20040826/#identifying_xop_documents
DBooth going over the primer
Sanjiva: primer shouldn't use "WSD"
proposal to use "DESCRIPTION" instead
DBooth to change "WSD" to "WSDL Document" throughout
DBooth: sections up to 3.1 should be ready to go
discussion on "WSD" and its use in the architecture document
Arthur: the primer should be completely self-contained
Roberto: web services architecture document is hard to understand without having some understanding of WSDL
DBooth: disagrees, wsarch document is quite readable
Anish: remove the architecture document reference and just have the glossary
Sanjiva: already section 1.4.5 of the wsarch document uses complex terms we don't use in our spec
... XML Schema primer starts from a simple example and grows it, it doesn't start with a glossary
DBooth: it's important to put WSDL in context
... our intent for the WSDL primer is to do as the schema one does
Kevin: instead of listing the wsarch document as prerequisite for the whole primer, we could list it in the section that contains the diagram
DaveO: the interactions described in the diagram must be understood to understand the place that WSDL occupies in the system
... the primer should not re-create a description of the architecture
Arthur: a primer is for a different kind of audience, so you want "progressive disclosure"
<dorchard> the first paragraph of primer introduction says "The text assumes that you have a basic understanding of XML 1.0 and XML-Namespaces."
<dorchard> schema primer
DBooth: prerequisites are only for information they should already know before they can start reading this document
Glen: strawpoll
DBooth: proposal to have more specific references for the concepts you need to know
<dorchard> "RTFA" :-)
accepted the proposal from DBooth
PaulD: primer should be an introduction to the WSDL spec itself, not to the whole industry
JM: are the editors getting sufficiently clear directions?
Dbooth: would lie down on the road about being inconsistent with the architecture document
<kliu> +1 to Dbooth
Sanjiva: in the spec we use "web service", not "provider agent"
DaveO: isn't that because the architecture document has a wider scope?
DBooth: the primer must provide a wider context than what the spec does
Roberto: proposal #1: CLIENT <-- WSDL --> WEB SERVICE
Dbooth: we could have Client (Requester Agent), etc
Tom: text can make references to requester agents and provider agents and point to the note
strawpoll: (1) use simplest terminology, (2) keep it consistent with wsarch document
(1) is client / WSDL document / web service
(2) is status quo
(2) means be as consistent as possible with the wsarch terminology
<youenn> +1 for 1
for (1): 6
<Allen> +1 for 1 for me too
for (1): 6
for (2): 7
Sanjiva: will lie down on the road on this
diagram revised to add "client" and "web service" in parentheses
Tom: objects to the use of requester agent and provider agent throughout
JM: formal vote on the same question of the strawpoll
IBM: 1
Sonic: abst
Sun: 1
BEA: 2
Macromedia: 1
Sonic: 2 (changed vote)
British Telecom: abst
Agfa: 2
W3C: 2
SAP: 2
Thomson: 2
Maryland: abst
Oracle: 2
Canon: 1
Roguewave: 1
results: 1 - 5, 2 - 7
Option 2 wins (i.e., be consistent with the WS Arch document, which uses "Requester Agent" and "Provider Agent")
Lunch - will resume at :15pm
<jjm> i.e. 19:10 CET
back in an hour!
<dbooth> Scribe: DBooth
<Marsh> Resuming
Roberto: Re: Diagram 2-1, please change "Web" to "Network".
DBooth: Ok.
GlenD: Too much stuff up front before the first example. Want to give a "hello world" example and then build on it.
DBooth: I agree. We need to reduce the Section 2 stuff a bit.
JMarsh: For example, section 3.3 has an explanation of all the MEPs. Does it need them all?
DBooth: No. I haven't reworked that part yet.
JMarsh: Let's focus on up through section 5 for the first WD, and leave the Advanced Topics for the moment.
Arthur: Primer should cover simple case and things that people often get wrong.
... Implementers often get inline schemas wrong.
Sanjiva: That doesn't belong in the Primer if it's an obscure case.
JMarsh: Maybe we should put an example of schemaLocation in the spec.
DBooth: Which Advanced Topics should move to the main body?
Bijan: Extensibility should move.
JMarsh: Import also.
PaulD: Maybe we should have another document that lists examples with their rationales.
JMarsh: Shouldn't our test suite catch that?
Sanjiva: If someone wants to do the work, fine, but let's not add it as a WG deliverable.
DBooth: How would this be different from the test suite?
PaulD: Different audience. Test suite would be for implementers; I'm talking about examples for WSD authors.
DBooth: Sounds like a prime area for training companies, books, etc.
JMarsh: Test suite should be linked from our status section.
GlenD: Take out the syntax summary.
DBooth: Need to merge section 2 into section 1, because it really is intro material.
Kevin: Should we define reusable types for contentType?
Anish: Two complex types, both are elements with contentType attributes.
JMarsh: Complex type would define an element with a contentType attribute. Extend it by annotating the value of the attribute.
... Instead of defining these types, you could have an import statement.
GlenD: This would be both an authoring convenience and tool help.
Roberta: If the expectedMediaType then you SHOULD set contentType, but in this case you're specifying contentType first.
GlenD: Optional would be useful for authoring convenience.
Sanjiva: How about defining type for all MIME types?
DBooth: I'm against authoring convenience. ;) I don't think the benefit is worth the cost.
JMarsh: We could add these to our existing schema, to be available for convenience.
RESOLVED: Add two complex types to our XML MIME schema, one derived from base64 and one from hexbinary.
(Discussion of whether to call the namespace prefix xmlmime: or mimexml: , because prefixes starting with "xml" are reserved.)
(Preference is for xmlmime: )
Type names will be base64Binary and hexBinary.
<tomj> Issue: http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5d
--- Issue LC5d ---
RESOLVED: Accept DBooth's proposed change in http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0008.html
--- Issue LC5f ---
(Skipped pending Roberto's action item on it)
--- Issue LC5g ---
Proposal to delete the word "agree".
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5g
JMarsh: What if the processor conforms to the WSDL part but not to an extension?
TomJ: A conformant processor MUST fail if it doesn't abide by the semantics of a required extension.
... I have 15 extensions in my WSD, and 5 are marked required. I MUST either conform to those extensions or fault.
GlenD: A conformant WSDL processor can legitimately AGREE to abide by the mandatory extension even if it doesn't ACTUALLY abide by it, because it's the extension plug-in's fault -- not the WSDL processor's fault.
<Jonathan> a conformance WSDL
<Jonathan> processor MUST immediately cease processing (fault) if it doesn't agree
<Jonathan> to fully abide ...."
RESOLVED: Accept the reviewer's proposal: "a conformance WSDL
processor MUST immediately cease processing (fault) if it doesn't agree
to fully abide ...."
--- Issue LC5h ---
Editorial.
--- Issue LC5i ---
JMarsh: This says "MUST" in a Note section.
TomJ: The reviewer is right that this Note is about the provider agent, whereas the section is about the requester agent.
Bijan: There are two kinds of dealing with this optionality. One is that the provider agent can't send a message using the feature until it gets a signal from the requester agent. The other is that the provider agent could send it in an ignorable way.
TomJ: This is about defining the semantics of optional extensions. We should move the gist of this to the section about optional extensions.
GlenD: Issue: When an optional extension is in a WSD, and you're building a provider agent, you must implement the extension.
DBooth: We need to say what is the meaning of an optional extension, i.e., that the service MUST support all optional extensions.
TomJ: I proposed to move this Note into the section on extensions.
JMarsh: We don't have a section on optional extensions.
... But the same material already appears in the section on Mandatory Extensions.
RESOLVED: Delete the note from the conformance section (as redundant), and promote the material on optional extensions into its own section, and add "See section ___ for further explanantion".
--- Issue LC5j ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5j
RESOLVED: Close LC5j as resolved by LC5i.
--- Issue LC5k ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5k
Bijan: This is just advice for implementers.
Dbooth: How about pulling this out into a Note and reworded as a suggestion?
RESOLVED: Delete the text, because it is only advice to implementers.
Hao: Why not just use xinclude instead of WSDL include?
JMarsh: They are semantically different.
(Discussion about whether xinclude must be supported.)
JMarsh: Our spec starts with the infoset, so how the infoset is obtained is out of scope.
(Further discussion about potential interop problems if we are silent about xinclude.)
Arthur: Should we specify minimum concrete serialization to guarantee interop?
JMarsh: WS-I Profile does that.
<scribe> ACTION: Arthur to submit proposal on conformance requirements for XML serialization (of WSDL and schema documents)
--- Issue LC5l ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5l
RESOLVED: Leave the Note, but change "processors" to "conformant processors" (and link to the conformance section), and explain this to the reviewer.
RESOLVED: Make the Note in 6.3 normative, and rephrase as "Extensibility elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users."
--- Issue LC6a ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6a
RESOLVED: Change {name} in F&P to {uri}.
(I.e., accept reviewer's comment.)
--- Issue LC6b ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6b
GlenD: The difference is necessary because it will allow schema processors to validate. It is a co-occurrance constraint.
RESOLVED: Reject the reviewer's suggestion, explaining that an element allows schema validation.
--- Issue LC6c ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6c
RESOLVED: Reject the reviewer's suggestion, and explain that we were following XML Schema's convention and that it further clarifies that it is the location of a WSDL document.
--- Issue LC6d ---
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6d
<Jonathan> #xmlns(http://bijan.com/mything)mything:frag(xoinxoinxoinxoinxon)
<Jonathan> #xmlns(mything,http://bijan.com/mything)mything:frag(xoinxoinxoinxoinxon)
<dorchard> http://www.w3.org/TR/xptr-xmlns/
(Discussion of how XPointer schemes work, and namespaces for them.)
JMarsh: Couldn't reuse our fragments on other media types.
(Much discussion of Appendix C section C.3.)
<Jonathan> #xmlns(xp,uri:1) xmlns(wsdl,http;//wsdl) xp:xpath(//wsdl:interface[@name='foo']]) interface(foo)
JMarsh: Might want to serve a fragment like the line above as XML media type. As the XPath is validated, I don't know if hte xpath part is on the component model.
<sanjiva> The chair demonstrates his XPointer legacy and prowess. ;-)
JMarsh: Two things to identify: either a WSDL component or an XML element.
<sanjiva> Hey, soap's @role can indeed be dereferenced:
<sanjiva> http://www.w3.org/2003/05/soap-envelope/role/next
<scribe> ACTION: JMarsh to take issue LC6d to XML Core WG
RESOLVED: We should accept the reviewers point about making explicit that we're defining a new scheme.
(Discussion of whether to consolidate the 6 schemes into a single WSDL scheme.)
The last part of this issue -- "the application/wsdl+xml MIME-type references this scheme as a possible xpointer scheme - i.e., I don't think a WSDL resource served as application/xml can ben resolved using this XPointer scheme." -- is postponed pending JMarsh's action item to talk with XML Core.
--- Issues LC7, LC10, LC12, LC15 ---
Editorial.
ADJOURNED