Minutes: 28 Jan 2004 WS Description FTF from Jonathan Marsh on 2004-02-04 (www-ws-desc@w3.org from February 2004)

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 4 Feb 2004 09:49:02 -0800
To: <www-ws-desc@w3.org>
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2027A6BC4@RED-MSG-30.redmond.corp.microsoft.com>

Web Service Description Group
Minutes, FTF meeting 28 Jan 2004
Bedford, hosted by Sonic.

irc: http://www.w3.org/2004/01/28-ws-desc-irc

Present:
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Adi Sakala IONA Technologies
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Umit Yalcinalp Oracle

Phone:
Allen Brookes Rogue Wave Software
Amelia Lewis TIBCO
Kevin Canyang Liu SAP
Jean-Jacques Moreau Canon
Sanjiva Weerawarana IBM
Prasad Yendluri webMethods, Inc.

Regrets:
David Booth W3C
Youenn Fablet Canon
Jacek Kopecky Systinet
Ingo Melzer DaimlerChrysler
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates

scribe: Adi Sakala

--------------------------------------------------------
Wednesday 28 January
--------------------------------------------------------
13:00 Introductions and logistics
- Assignment of scribes
(Igor Sedukhin), Adi Sakala, Arthur Ryman, (Prasad Yendluri),
(Dietmar Gaertner), Tom Jordahl, (Jeffrey Schlimmer),
Philippe Le Hegaret, William Vambenepe, Umit Yalcinalp
- Agenda bashing

Scribes: Adi, Arthur, Tom, William, Philippe

-------------------------------------------------------
13:10 Publication plan
Survey of remaining work
Part 1: Open issues:
misc (16)
editorial (2)
Part 2: Open issues:
misc (1)
editorial (1)
Primer: ?

Resolve the current 17 issues and 3 editorial issues. Should be able
to go to last call on all parts by May and internally freeze within
the working group by March.

Primer by may should be mostly in the hands of editors.

RDF mapping of wsdl 2.0, this proposal will be done parallel to other
specs.

Charter says we have a testsuite deliverable.

Test Assertion Document:

Paul: Says it is very important for people looking at these specs
and trying to evaluate.
Philippe: Testsuite could be owned by other groups not necessary by
wsdl working group.
Arthur: The eclipse project hosts the java implementation of
wsdl and has test assertion document for wsdl 1.1. It would
be a good idea to have blessing from group for 2.0 assertion
document. Is there an easy way to reference to spec from the
test assertion document?
Paul: It would be a good idea to have the document done here so
that other groups can refer to it like ws-i.
JMarsh: Resource constraints.
Philippe: How did xmlp group did this?
Glen: Took all the assertions in the spec and converted them into
test cases and the actual testing was done by soap builders.
Jeff: Can't really have a framework due to licensing issues.
JMarsh: Have a bucket of wsdl's valid and invalid and make them as
test cases.
Glen: It would be a good idea to go one step forward and actually
define how the wire messages look when something is defined
in wsdl.
Arthur: Explains how eclipse does the validation of wsdl.
Glen: Wsdl 1.1 has lot of problems due to not having wire traces
as test collection.
JMarsh: Need to have a scope so that we can achieve it
appropriately as this is a big area.
Arthur: If we host it at eclipse, companies who doesn't like
opensource won't like referencing it.
Dave: Working group produces the interoperable spec. I think it
should be hosted by wsdl working group.
Robert: Should we have bug tracking system, nightly builds etc.
Arthur: The current goal would be to have a test assertion document
which eclipse can take and build test cases and run through
their validator.
Paul: There is a commercial value in this document and we should
not sacrifice that value.
JMarsh: It looks like there is an agreement to host test assertion
document here. Whether it should be in the same document
or as a separate document.
Jeffm: Having markup is a starting point but not a test assertion
document itself.
Glen: There are assertions in spec and there are n number of
things that each assertion can fanout for testing.

RESOLUTION: we should have a separate document for test assertions
and this document has to be explicitly linked to the
spec.
ACTION: Phillpe and JMarsh will look at the ipr for test suite.
RESOLUTION: Arthur is the Editor for this document.

-------------------------------------------------------
13:30 Faults
- Issue 105: Abstract Faults [3]
Work through some WSDL examples to verify that Paul's
fault proposal [4] doesn't negatively impact bindings.

[3] http://tinyurl.com/ysgl#x105

Pauls Proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html
TomJ: writing some fault samples on white board for discussion.

Roberto: The intent of soap spec is people should be able to resolve
faults by looking at faultcodes instead of digging into
detail element.
Glen: In wsdl we should be able to specify the hierarchical fault
codes that soap allows.
Umit: How to distinguish faults on per operation basis.
Glen: Message should really be element as it really pointing to
element.
Umit: Should we be able to allow two soap faults to be associated
to a single fault definition.
Glen: You can bind one of the fault at the top level and define
more specifics at the operation level.
Paul: The binding spec is behind. I don't think someone looked
into it.
Roberto: It should be something like <outfault ref="tns:BadTicker"/>
I think it should be "ref", because we usually use "name"
when defining a new component, not in references.
Bijan: I just want to note that the issue of renaming message
(especially to *element*) touchs on an action item of mine
(that I'm finally understanding). First, I understand
message to mean message*type*. If so, I don't want to
restrict messageTypes to elementTypes.
Tom: Take fault to fault in binding and just don't give any
flexibility to override for different operations.

RESOLUTION: Accept Paul's proposal to hoist faults in the interface.
RESOLUTION: Rename faultDefault to fault.
RESOLUTION: Allow <value>,<subcode> as children of
<wsoap:fault[Default]>.
RESOLUTION: Remove per-operation (in|out)fault
NEW ISSUE: Open issue on the name of wsoap:fault/@name and
outfault/@name (should indicate that it is a reference,
not defining a name)

ACTION: Sanjiva to consistify the @name attributes.

-------------------------------------------------------
14:00 Issue fault-name-uniqueness [5]: Should faults be named with
QNames? In WSDL 1.1 fault names are NCNames which are not unique
within portType even. This leads to a cumbersome mechanism to
uniquely identify a fault.
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html
[5] http://tinyurl.com/ysgl#xissue%20fault%20name%20uniqueness

Glen: Why cant we make interface names as URI's so that binding
makes easy.
Dave: How does symbol namespaces effect this??
Glen: What if we make targetNamespaces of wsdl as part of the
namespace and combine it with interface name to make a URI?
Eg: wsdl namespace http://foo.com, interface A, operation
getFoo. Then referring to operation will be Qname of,
http://foo.com/A, getFoo
Roberto: Explaining the uniqueness of operation in case of
inheritance scenario. Qname of operation name should be
unique in the context of an Interface.
[2nd Issue in Faults closed.]

RESOLUTION: Close issue-fault-name-uniqueness - works just like
operations.

-------------------------------------------------------
14:15 Issue 89: Binding message references in component model [6]

[6] http://tinyurl.com/ysgl#x89

Roberto: Create two message reference components at binding level
to be in consistent with abstract level. With the fault
resolution at the binding this might not be an issue
anymore.
Sanjiva: We need to keep things in consistency.

RESOLUTION: Close issue 89 by changing the namespace of wsoap:fault
to wsdl:fault, and add a corresponding component in the
abstract model.

15:00 Break

-------------------------------------------------------
15:20 Issue 87: Redundant direction information [38]
Options:
a) Drop direction property.
b) Retain direction property.

[38] http://tinyurl.com/ysgl#x87

JMarsh: Redundant direction information in our abstract model.
TomJ: What would be ramifications for removing this model. This
information is useful to validate the part 1 information
that it is pointing to appropriate MEP.
Glen: MEP has appropriate names and by looking at it you know
what you are doing.
Sanjiva: Removing the direction property. Since now we made
messageReference optional, by using input and output name
you can determine the direction.
JMarsh: How does this work when you use defaulting model. And if
we don't understand the message pattern then this property
should be useful.
RESOLUTION: Close issue #87 with no action.

-------------------------------------------------------
15:30 Optional Extensions (Latest Issue from Email thread [.1]):

[.1] http://www.pacificspirit.com/blog/2004/01/28/extensibility_and_ignore_rule_in_web_architecture

Glen: The issue here is our spec doesn't say anything about the
processing of extensibility elements.
Dave: What if somebody ships a processor that has a default
behaviour and throws error on every optional element. The
wording in spec should ensure us.
Paul: There is a must understand tag.
Dave: The default is if we don't specify must understand the
processor should continue processing and not fail.
Jeff: Want to have a policy for faulting on unknown things.
Agrees with backward compatability argument of dave but
would like the wording in such a way that if process wants
to fail they can fail based on a policy.
Dave: This is a problem with the using should and must.
Glen: Optional extensibility elements should be ignored.
Robert: If we agree on marking it as should understand, can we
produce a test assertion for this.
Glen: SOAP has these constraints in the spec so that tests can
be shown to work.
Dave and Roberto: Optional extensibility elements must be ignored.
Arthur: What happens in generating code, rendering html, editor
editing WSDL etc.
Umit: If I process an extensor and mark it in the abstract model
how do I know which state I am in?
Dave: We can live with should ignore as long as we have test
cases in the test assertion document.
Prasad: +1 to DaveO's latest proposal; SHOULD ignore with some of
the execeptions enumerated
Philippe: "Optional extensions MAY be ignored. Unknown optional
extensions SHOULD be ignored" "Known optional extensions
SHOULD be processed. Unknown optional extensions SHOULD be
ignored"?
Prasad: How about optional extensions a WSDL processor can not
process successfully SHOULD be ingored :)
DaveO: Roberto brought up the issue of conformance.
JeffM: Prasad, the conformance issue is how to have a conformance
test with a SHOULD as opposed to a MUST.
Prasad: Thanks Jeff. Yup thats always an issue. However conformance
testing should not be a sole criteria why something is a
SHOULD. MUST is a *bad* choice here. HTML and WSDL are
very different though. What applies to HTML is not at all
applicable to WSDL IMHO.

Straw Poll
Question:
1. Statement in spec, that a wsdl processor MUST ignore the optional
extensibility element.
2. Statement in spec, that a wsdl processor Should ignore the
optional extensibility element.

No Resolution and still an OPEN ISSUE.

-------------------------------------------------------
16:30 Joint Session with Arch WG
- Summary of Arch deliverables and areas WSDesc should be aware of
- Use Cases document disposition
- Issue 90: Synchronize terminology [7]
- Issue 75: Incoherence between WSA and WSD MEPs [8]

[7] http://tinyurl.com/ysgl#x90
[8] http://tinyurl.com/ysgl#x75

- WSA now have a much more useful usage scenario document now.
- WSD group is lack of resources to work on this document moving
forward.
- Need to review the work done by the WSA working group on usage
scenario.
- talking about glossary and inconsistency of terminology in the
WSA specification documents.
- The hope is to adopt the WSA terminology in the WSDL working group.
- WSA group will be flagging gap about soap intermediaries.

17:30 Adjourn

Received on Wednesday, 4 February 2004 12:49:18 UTC