- From: Jacek Kopecky <jacek.kopecky@deri.org>
- Date: Fri, 22 Oct 2004 18:35:19 +0200
- To: WS-Description WG <www-ws-desc@w3.org>
Web Services Description Working Group;
2004-10-21 conference call minutes
Attendance:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Hugo Haas W3C
Tom Jordahl Macromedia
Anish Karmarkar Oracle
Jacek Kopecky DERI
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jean-Jacques Moreau Canon
David Orchard BEA Systems
Asir Vedamuthu webMethods
Prasad Yendluri webMethods, Inc.
Regrets:
Erik Ackerman Lexmark
Helen Chen Agfa-Gevaert N. V.
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM
Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0056.html
Scribe: Jacek Kopecky
--------------------------------------------------------------------
2. Approval of minutes
Marsh: late regrets not cause for re-issue of minutes
Marsh: Hugo sent correction on LC21, on today's agenda
Marsh: minutes as mailed are approved
--------------------------------------------------------------------
3. Review of Action items [.1]. Editorial actions [.2].
PENDING 2004-04-01: Marsh will get schema tf going.
PENDING 2004-09-02: Bijan to create stylesheet to generate a
table of components and properties.
PENDING 2004-09-16: Editors to move App C to RDF Mapping spec,
except the frag-id which will move
within media-type reg appendix.
PENDING 2004-09-16: Editors to fix paragraph 6-9 of section
2.1.1 moved into 2.1.2
which talks about the syntax.
PENDING 2004-09-16: Hugo to get a URI to use for DTD example
in Appendix E.1 (LC38)
DONE [.3] 2004-09-16: Glen to CC Asir on mail to Marc re: SOAP modules
and features (LC18, LC29b)
DONE 2004-09-30: Marsh to ask Glen about how LC9 is going.
NEW ACTION: Respond to Tim on LC9.
PENDING 2004-09-30: Arthur to add Z notation to Part 1.
PENDING 2004-10-07: Paul to set up test suite directory
structure (Hugo assist)
PENDING 2004-10-07: Primer editors to use the new
terms "Web service" and "consumer|client".
DONE [.4] 2004-10-07: Asir to detail binding changes
or justify why they aren't necessary (LC19)
PENDING 2004-10-14: Arthur to prototype a javascript
implementation and decide on the two doc's
vs javascript method later.
DONE 2004-10-14: Hugo to check with pub team to
investigate the preferred method of
publishing a Rec. with multiple viewing
options...which is normative, which
browser is the Gold Standard for publishing,
symbol font/encoding requirements etc.
hugo: on Z-notation: multiple versions should not be done using
javascript because of support issues, especially for printing
hugo: we should also not use the "symbol" font because of web character
set issues
hugo: I have a list of fonts with math characters
Marsh: so we won't provide a version for people without fonts with the
appropriate unicode characters, but we may provide links to fonts
Marsh: z-notation spec will be normative, other version linked from
that
NEW ACTION: Hugo to generate a summary.
DONE 2004-10-14: Anish to integrate the resolution
to MarkN's comment into the document
and move forward towards publication.
(Backup work item to JMarsh if Anish
unavailable to.)
PENDING 2004-10-14: Editors to add a statement like:
The Style property may constrain both
input and output, however a particular
style may constrain in only one
direction. In Section 2.4.1.1 of Part 1.
(subsumed by LC21 resolution?)
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/actions.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0058.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0057.html
--------------------------------------------------------------------
4. administrivia
Marsh: Peter from Agfa resigns
Marsh: Nov f2f registration closing soon
Marsh: may have to leave early on Thursday, Hugo might chair it after
that
Marsh: next f2f meetings?
Marsh: we have quite a bit of work still, some comments still coming
Marsh: so we may try a f2f in January, next chance would be in March at
TP
pauld: could we coordinate with ws-addressing?
Marsh: overlap seems to be big enough, would make sense
Marsh: this is also important for tech plenary non-overlap preferences
Marsh: Mo-Tu or Th-Fr at the tech plenary meeting?
mixed preferences voiced
Marsh: perhaps we could do 2-2.5 day meeting in January
<pauld on irc> ws-addressing plans to meet every 6 weeks
Marsh: I'll try to pursue this with Addressing WG
--------------------------------------------------------------------
5. new issues
Marsh: added a bunch of LC issues
Marsh: we can still expect Schema comments
--------------------------------------------------------------------
7. media type description deliverable
Marsh: we have all approvals, only "manual labor" necessary for
publishing, let's shoot for Monday
Anish: need status section from DBooth
--------------------------------------------------------------------
8. media type registration
dbooth: got two private messages on the registration mentioning the
SOAP media type registration; I have some verbiage from the old version
of that
dbooth: there's another step or two in the process
Marsh: this media type would not be allowed for use with WSDL 1.1, any
issues with this?
--------------------------------------------------------------------
9. new editorial issues
Marsh: any objection to referring the issues from the agenda directly
to the editors?
no objection
--------------------------------------------------------------------
10. LC21
Marsh: should we wait for Arthur?
hugo: Arthur was saying HTTP binding need not be restricted to
particular MEPs
hugo: I thought Arthur's comment was that the HTTP binding was only
supporting in-only and in-out and he said it can also work with out-only
and out-in, and possibly robust-out-in
<asir on irc> Today, HTTP Binding supports -
'http://www.w3.org/2004/08/wsdl/in-only',
'http://www.w3.org/2004/08/wsdl/robust-in-only' or
'http://www.w3.org/2004/08/wsdl/in-out'.
<asir on irc> see,
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#http-operation-decl-dest
Jacek: the HTTP binding doesn't really support robust-out-in and
robust-in-out because of the third message - optional fault
Marsh: in order to use out-in we have to have out-of-band info, could
such info also be used for the optional final faults?
Marsh: we'd have to tell people they need additional information to use
the out-first MEPs
Marsh: although the issue mentions multipart, we're not really talking
about multipart
Marsh: proposal: add the other MEPs (except for robust-in-out and
robust-out-in) to the list of supported MEPs in our HTTP binding
Marsh: proposal cont'd: and add some text that additional info is
necessary
asir: does this impact the binding description in part 3?
hugo: not really, I don't think so
Marsh: any objections to adopting the proposal?
no objections
ACTION: editors
ACTION- 2
hugo: the issue actually does talk about multipart
Marsh: the proposal above just arose in discussion of LC21, does not
solve it really
hugo: I don't think the multipart style is concerned with the MEPs
Marsh: proposal: remove the sentence that multipart style can only be
used with some particular MEPs
hugo: same question for the URI style
hugo: I'd make the change (drop the restriction) from multipart style,
leave it in URI style
Marsh: I don't see a reason to bind a style to MEPs
<Roberto on irc> +1
Marsh: proposal update: let's make styles orthogonal to what MEPs are
used, removing the appropriate sentences from URI style and multipart
style
hugo: I think it's OK
jacek: +1
Roberto: +1
Marsh: any objection to updated proposal?
no objection, restrictions on MEPs in styles removed
<Marsh on irc> ACTION: Editors remove 2nd paragraph of 3.9.1 and 3.9 2
(Part 3) - mep dependency.
--------------------------------------------------------------------
11. LC29e
hugo: we made a decision about treating nils when serializing into the
request URI, we should probably make the same decision for serialization
in parameters
hugo: if an element is not present, the parameter won't be either, but
if the element is present with nil, the parameter might be empty or
something
Marsh: if we're losing information, we should make it an error
Marsh: ... in various sections in 3.8
Marsh: we had decided that nil would be an error in cited elements,
we're extending that now to uncited elements as well
<hugo on irc> http://www.example?foo=
Marsh: if there is an empty element, it would be serialized as an empty
parameter ( foo= )
Marsh: any objection to these extensions?
no objections
--------------------------------------------------------------------
13. LC5f
<Marsh on irc>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0027.html
dbooth: one sentence may need to be dropped
dbooth: it was the MAY near the top
dbooth: in the definition of error, the sentence with "MAY recover from
it" should be eliminated
dbooth: it gives the impression that software may be lax in enforcing
WSDL spec
Marsh: that would collapse errors and fatal errors?
Roberto: no, non-fatal errors may be recovered from
dbooth: if you actually detect an error, you must report it, if however
you don't detect an error somewhere (because a part of a doc is not
processed) you will ignore it
dbooth: so I'd drop the sentence with the 'MAY's
dbooth: we should be clear that if an error is in fact detected, a
processor should stop and report it
jacek: should non-fatal error be one which can be recovered from by
acting as though that part was not processed?
dbooth: I don't want to encourage lax error processing
Roberto: I think there are errors that processors can recover from
without reporting them and stopping
Roberto: e.g. a message using an XML declaration that cannot be found,
a processor may choose to treat it as "any"
dbooth: I think these processors are in the long run dangerous,
encouraging laxness
Marsh: there are conditions like network status that may cause such
errors
jacek: starting to agree with dbooth
Marsh: Roberto's suggestion came from the non-lax XML spec
Roberto: most things are fatal errors
Roberto: non-fatal errors: non-resolvable import
Roberto: or referencing an XML element declaration that's not known
Jacek: I'd treat the last as a fatal error
dbooth: could we just say "SHOULD fault"?
dbooth: if it actually detects an error
dbooth: I'm trying to make a difference between saying a processor
"should detect" or that "if it actually does detect it, it should
report"
Roberto: but may recover?
dbooth: I'd prefer to drop the part about recovery
dbooth: I'd like: "should report an error."
dbooth: the work "recover" implies that the info was needed but we're
talking about the case where the info is not really needed
Marsh: converging on changing the last sentence of defn of an error to:
"conforming software that detects an error should report it and may
recover from it"
dbooth: don't like the recover part
Marsh: we may see all the cases and end up with never using the
non-fatal error
Marsh: let's try and look at what we consider non-fatal errors
Roberto: what's not listed in my email is a regular (non-fatal) error
dbooth: it's a bit hard to see those now
Marsh: Roberto could list the things usefully classified as non-fatal
errors
Roberto: I can try and list some non-fatal errors
ACTION: Roberto to list some non-fatal errors for consideration if
that's useful
Received on Friday, 22 October 2004 16:35:53 UTC