W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2004

Minutes, 21 Oct 2004 WS Description WG

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>
Message-Id: <1098462919.3034.44.camel@Kalb>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:33 GMT