- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 17 Sep 2004 17:42:12 -0700
- To: <www-ws-desc@w3.org>
Web Services Description F2F
Tuesday 14 Sep 2004
See also: IRC log [http://www.w3.org/2004/09/14-ws-desc-irc]
Attendees:
David Booth W3C
Helen Chen Agfa-Gevaert N. V.
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Hugo Haas W3C
Hao He Thomsona
Tom Jordahl Macromedia
Anish Karmarkar Oracle
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Sanjiva Weerawarana IBM
Phone:
Allen Brookes Rogue Wave Software
Youenn Fablet Canon
Jean-Jacques Moreau Canon
Regrets:
Amelia Lewis TIBCO
Asir Vedamuthu webMethods
Logistics [1].
[1] http://www.w3.org/2002/ws/desc/4/04-09-f2f.htm
--------------------------------------------------------
Tuesday 14 September
--------------------------------------------------------
09:00 Introductions and logistics
- Assignment of scribes
Roberto Chinnici, Sanjiva Weerawarana, Kevin Canyang Liu,
Tom Jordahl, Prasad Yendluri, Paul Downey, Hugo Haas,
David Booth
Scribes: Roberto, David, Kevin, Sanjiva, Paul, Tom
<Roberto> Scribe: Roberto
- Agenda bashing
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.
--------------------------------------------------------
09:05 Spec status overview: Media Type Description Note [2]
- Finalize plan to issue as Last Call
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t
ypes.html?content-type=text/html;%20charset=utf-8
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
Jonathan: There's also a thread on 252 started by Umit.
RESOLUTION: consensus not to reopen 252 based on Umit's mail.
Jonathan: 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"
RESOLUTION: Consensus to remove sentence "the annotation should be
considered only as a hint."
Jonathan: 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.
Hao: 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.
Jonathan: Do we need to require that implementations signal the same
errors?
Tom: Proposes to require contentType when expectedMediaType has
a wildcard.
Jonathan: 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."
RESOLUTION: Consensus on adding "When expectedMediaType is used and has
a wild card or list, you SHOULD write your message schema to
require a contentType."
DBooth: Who should register the media types?
Jonathan: The WG, but no specific person.
<dbooth> Info on how to register the media type:
http://www.w3.org/2002/06/registering-mediatype
Jonathan: Call for volunteers to manage the registration of our media
type.
Arthur: Which extension should we use? .wsdl? .wsdl20?
[.wsdl seemed to get consensus]
DBooth volunteers.
<anish> html media type rfc -- http://www.ietf.org/rfc/rfc2854.txt
<anish> xop media-type --
http://w3c.org/TR/2004/CR-xop10-20040826/#identifying_xop_documents
<sanjiva> +1 for .wsd and .wsdl because our WG is called WS-D too :(
Jonathan: No other media type issues. Do the edits tonight, then have
everybody review the document tomorrow and discuss any new
issues on Thursday.
10:40 Break ----------------------------------------
--------------------------------------------------------
11:00 Spec status overview: Primer [3]
- Finalize plan to issue as 1st Working Draft
[3]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.ht
ml
DBooth going over the primer
Sanjiva: Primer shouldn't use "WSD"
[Proposal to use "DESCRIPTION" instead.]
RESOLUTION: 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" :-)
RESOLUTION: Accepted the proposal from DBooth to have more specific
References for the concepts you need to know.
PaulD: Primer should be an introduction to the WSDL spec itself,
not to the whole industry.
Jonathan: 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
<Allen> +1 for 1 for me too
for (1): 6
for (2): 7
Sanjiva: Will lie down on the road on this.
RESOLUTION: Diagram revised to add "client" and "web service"
in parentheses
Tom: Objects to the use of requester agent and provider agent
throughout.
Jonathan: Formal vote on the same question of the strawpoll
1: IBM, Sun, Macromedia, Canon, Roguewave
2: BEA, Sonic, Agfa, W3C, SAP, Thomson, Oracle
Abstain: British Telecom, UMD
Results: 1 - 5, 2 - 7
Option 2 wins (i.e., be consistent with the WS Arch document, which uses
"Requester Agent" and "Provider Agent")
12:15 Lunch ----------------------------------------
<dbooth> Scribe: DBooth
13:15 Primer (cont.)
Roberto: Re: Diagram 2-1, please change "Web" to "Network".
DBooth: Ok.
RESOLUTION: Change "Web" to "Network" in diagram 2-1.
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.
--------------------------------------------------------
14:00 Reusable Types for ContentType?
[New issue raised by Kevin.]
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.
RESOLUTION: 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.
--------------------------------------------------------
14:30 Spec status overview: SOAP 1.1 binding
- SOAP 11 Binding, first draft [4]
- Modified Part 3 (aka, added soap version) [5]
- Modified XML Schema for SOAP in WSDL 2.0 [6]
- Collect issues
- Finalize plan to review
[4]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11-bi
nding.html?content-type=text/html;%20charset=utf-8
[5]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/mod-wsdl20-bindi
ngs.html?content-type=text/html;%20charset=utf-8
[6]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/mod-wsdl20-soap.
xsd
Nothing to say without Asir - skipped.
14:35 Spec status overview: RDF Mapping
- Status update? First peek?
Postponed till Thursday.
14:40 Last Call issues [7]
- (In issues list order, with Asir's last if possible)
[7] http://www.w3.org/2002/ws/desc/4/lc-issues/
Last Call Issues
<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
ACTION: Editors to implement resolution to LC5d at
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 conformant WSDL processor MUST immediately cease
processing
(fault) if it doesn't agree to fully abide ...."
RESOLVED: Accept the reviewer's proposal: "a conformant WSDL processor
MUST immediately cease processing (fault) if it doesn't agree to fully
abide ...."
ACTION: Editors to implement resolution for LC5g as proposed.
--------------------------------------------------------
--- Issue LC5h ---
RESOLUTION: reclassify as 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".
ACTION: Editors to implement resolution to LC5i.
--------------------------------------------------------
--- 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.
ACTION: Editors to implement resolution to LC5k.
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.
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."
ACTION: Editors to implement resolution to LC5l.
--------------------------------------------------------
--- 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.)
ACTION: Editors to implement resolution to LC6a.
--------------------------------------------------------
--- 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
Supports schema validation by allowing a co-constraint between
'value' and 'constraint'.
--------------------------------------------------------
--- 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
(Discussion of how XPointer schemes work, and namespaces for them.)
<Jonathan>
#xmlns(mything,http://bijan.com/mything)mything:frag(xoinxoinxoinxoinxon
)
<dorchard> http://www.w3.org/TR/xptr-xmlns/
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 the
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
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.
ACTION: Editors to make explicit that we're defining new XPointer
Fragment schemes.
(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 be resolved using
this XPointer scheme." -- is postponed pending JMarsh's action item to
talk with XML Core.
--------------------------------------------------------
--- Issues LC7, LC10, LC12, LC15 ---
Editorial.
ACTION: Editors to implement LC7, LC10, LC12, LC15 unless they find
problems that require additional group attention.
17:00 Adjourn
Received on Saturday, 18 September 2004 00:42:45 UTC