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

Minutes, 15 Sept 2004 WS Desc FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 17 Sep 2004 17:43:07 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA204E9AB6D@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Services Description F2F
Wednesday 15 Sep 2004
See also: IRC log [http://www.w3.org/2004/09/15-ws-desc-irc]

 David Booth            W3C
 Helen Chen             Agfa-Gevaert N. V.
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 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

 Allen Brookes          Rogue Wave Software
 Youenn Fablet          Canon
 Jean-Jacques Moreau    Canon

 Hugo Haas              W3C
 Amelia Lewis           TIBCO
 Asir Vedamuthu         webMethods 

Scribe: Kevin Liu

Wednesday 15 September
09:00 Last Call Issues

Jonathan:  Arthur has a call till 10am. agenda this morning changed.
           Continue last call issues.

Issue LC8: "Permit URI References instead of URIs "
Roberto, Jim: text sounds like encoded
[Roberto: http://www.w3.org/TR/xmlschema-2/#anyURI]
Roberto referred to schema spec for uri reference
DBooth:   What do we need to do?
Roberto:  Use URI reference, use the same trick as schema.
[Group looks at schema spec part 2 section 3.2.17 for anyURI]
Bijan:    Using qname is more consistent with rest of the spec?
Glen:     We had discussion in Palo Alto, was for it, but it 
          was shut down.
Roberto:  Find out where we are using anyURI type. 
Jonathan: And figure out whether we should allow URI reference
[more discussion on using frag id]
[dbooth:  "As such, the fragment identifier is not used in the 
          scheme-specific processing of a URI; instead, the fragment 
          identifier is separated from the rest of the URI prior to a 
          dereference, and thus the identifying information within 
          the fragment itself is dereferenced solely by the user agent 
          and regardless of the URI scheme."]
DBooth, Roberto, Jonathan: what to do in the spec?
[Frag id is stricken out before deferencing. It's up to applications
how to deal with it.  It's web arch issue, nothing specific to web
Seems schema spec doesn't really say anything about anyURI's value
Jonathan: Gave three example URI's in white board (using e-acute vs. 
          %-escaped value), all same except some contain spaces. Are 
          they all the same value space?  They are in different
          so ns processor treat them differently.
[hugo: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#uricompare]
JM checking section 2.19 of part 1 for our definition of "comparing
Jonathan: If we add a frag id to the end of any of the uri, it's
          Don't see problem allowing frag in URI.  We are OK with frag
[Our def of uri need a little update to make it clear its actually uri
Sanjiva:  Why not define our own type?
Jonathan: We should keep our type as close to schema as we can.
ACTION:   Editors update spec to clarify our using of anyURI is actually

          URI reference except targetNS
RESOLUTION: LC8 closed by allowing # everywhere but targetNamespace.

Issue LC9: How does the Operation Name Mapping Requirement (Part 1,
section relate to interface inheritance?

Glen:     It's is not only for operation name, a general composition
          Spec is not clear. We should add a paragraph to clarify this.
DBooth:   We already have a section for that.
Glen:     We need to answer Tim.
[The answer to his first question is yes, but what to do with spec is
not yet clear.]
DBooth:   Conformance section says something.  (section 6.1)
ACTION:   Glen to respond to Tim saying yes to his first question, 
          and pointing out sections 6.

Jonathan: Answers to Tim's three questions: yes, n/a, no
[dbooth: Operation name mapping requirement:
[Disscusion on what to do with spec/]
Glen:     Section2.2.1.1 should be clarified.  When you are using a
          it's got an interface, plus we should write it in English :)
ACTION:   Editors to clarify spec about operation name mapping
          by moving paragraph preceeding section and whole 
          to service section, and clear up the text.
[Marsh:   RESOLUTION: LC9 closed]

[dbooth:  The intent of this action is to associate the operation name 
          mapping requirement with a *service* rather than an interface,

          so that the requirement only applies when an interface is
          used by a service.]
[GlenD:   Clarification on this action - "clear up the text" means 
          1) make clear that this applies to the interface component of 
          the service component, and 2) indicate that any in-scope
          or extension (scoping of extensions left as an exercise to the

          author) may satisfy the ONR]

[dbooth:  This also means that the prose in list item 1 of " 
          Operation Name Mapping Requirement" should NOT refer only to 
          properties of the interface component, due to the F&P 
          inheritance rules defined in e.g. " Feature Composition

11:00 Break     ----------------------------------------

11:30 Zed notation update/QA issues

Arthur is ready to present Zed notation 
Authur:   will send material to www archival mail list .  Basically we
          an xml source, it can be translated naturally into math and 
          generate test assertions.
[dbooth:  Arthur draws on the board:
 |          XSLT
 | XML ------------> HTML + CSS
 | \
 |  \    XSLT            fuzz
 |   \----------> Tex ---------> TypeErrors
 |                 \
 |                  \   Tex
 |                   \-------> PDF
Hugo, Roberto are concerned about browser sniffing
Arthur:   Shows chart for "rendering Z notation symbols in a web page"
          demos how IE and Mozilla behave differently.
[pauld: arthur's question to the mathml WG:
Arthur:   Demos how fuzz does type check and generates type errors
          and think fuzz type checking is quick and useful.  Addreses 
          hugo's concern on browser dependency for rendering the zed 
          html. It will be problem for this generation is to be
          in W3C if browser dependency issue can not be solved.
[Now group discusses how this affect our spec assuming rendering problem
can be fixed.]
Arthur:   Shows a generated normal version of wsdl2.0 spec and how
          component looks like. It has mathematical expression and
[alewis: url?]
Sanjiva:  Is concerned changing the spec after the last call.
[it's ok to add to what's already published.]
DBooth:   This is not change to the semantic of the spec.
Anish, Roberto: Aare concerned another additional presentation will add 
          more confusion.
[We already have component model, infoset model, now add zed notation?]
dbooth:   There are a few ways to go: 
          1. replace the current notation, 
          2. in addition to current notation...
Paul:     Find zed is easier to read than informal notation
Sanjiva:  Would like to see how the spec looks like with this new
          before we decide anything.
[Now discuss possible impact on our publication schedule, may need
another last call.]
ACTION:   Arthur to (re)write a subsection of the spec to show exactly
          it looks with the Zed notation included before next telecon.
ACTION:   Hugo to investigate potential options for get the Zed version 
          published in W3C web site.
Tomj:     Is concerned adding the z will make the spec more intimidating

          to read.
Arthur:   Will do this for QA anyway. Doesn't hurt to give it a try with

          the spec, we will see how people feel about it
[Arthur:   fyi, I posted the pdf of the XML Infoset Spec to
[Arthur:   The Z notation for it, that is]
[Arthur:   Watch the www-archive - I posted it too but it hasn't shown
           in the list yet.]

12:45 Last Call issues [8]
    - (In issues list order, with Asir's last if possible)

 [8] http://www.w3.org/2002/ws/desc/4/lc-issues/

Issue LC29a:  It's unclear why default binding rules are not defined for
fault components.
Roberto:  Useful info in binding fault is the code and subcode, there is

          no good value to provide as the default code and subcode.
RESOLUTION: Add a rationale to the spec explaining there is no good 
            default value for code and subcode.
ACTION:   Editors to add rationale to spec to explain why no default for

          binding fault is defined (no good default codes)
Tomj:     Suggests involving a tech writer to inspect the spec and fix 
          similar issues.
Hugo:     You need to spend a lot of time to talk to a tech writer to 
          get the job done.
dbooth:   Not sure the result will be significantly better.

13:00 Lunch     ----------------------------------------

[dbooth: Scribe: Sanjiva]

14:00 Individually read the Media Types Spec

[tomj: http://tinyurl.com/6mvur]
[sanjiva: we're spsed to be reading the media types spec now ..]
[dbooth: My talk on What's New in WSDL 2.0:

14:15 Additional media type comments

Discussion about rationale for why the expectedMediaTypes attribute has
restricted MIME parameters to the 'q' parameter.
Sanjiva:   Make it be consistent with what HTTP has unless we have good 
           reason not to.
Jonathan:  Is this totally congruent to accept header, which would 
           rationalize following HTTP rules?
Tom:       Doesn't think so
[hugo: Minutes from last discussion:
[tomj:     q is the only argument to the Accept header in section 14.1.
           The other arguments are extensibility, and we don't want or 
           need the extensibility point here.
           So we are not limiting a list of things to just q, we are 
           supporting all the specified options, but none of the 
           "accept-extension" options.]
Straw poll on whether to follow Accept: or whether to restrict the value
to be only with the q parameter without the extension capability.
  Yes change to follow the http spec: 4
  No leave it alone: 4
[Allen: abstain]
[youenn: abstain also]
take the vote again because of some flip-flopping...
  Yes: 6
  No (status quo): 4
Objections to moving forward? Tom can't live with it.
[pauld:    Voted in order to loose the schema pattern ]
Tom:       Change the status quo to say "we allow the parameters defined

           by http ('q') but we don't allow the extensibility".
Discussion about why we change the actual syntax from what's in HTTP.
Sanjiva:   Proposes to change the syntax to follow the http spec, drop 
           the pattern facet from the schema, and say that the format of

           the string which follows the appropriate production in the 
           HTTP RFC (except for not supporting extensions)
Jonathan:  Any objections to the above?
Nope, we're all happy campers.
ACTION:    Media type editors to change the syntax to follow the http
           drop the pattern facet from the schema, and say that the
           of the string which follows the appropriate production in the

           HTTP RFC (except for not supporting extensions).

Tom:       The media type document doesn't seem to explain how this 
           actually fits together .. 
DaveO:     Write a primer for the media types spec?
Tom:       What about an overview section? Words like "here's the 
           problem we're trying to solve, you put this stuff in the 
           schema, then at runtime this happens and this is how it
Consensus to add some more text in the introduction.
ACTION: Tom and Anish to figure out the right words.

Jonathan:  Status section of the doc has "Second Public Working Draft" 
           incorrect capitalization and too many words in the link.
The status section is going to change anyway .. so above comment will
get fixed automatically.

Jonathan:  2nd bullet of requirements has redundancy in the last
           combine with previous occurrence.
ACTION: Media Type editor to remove last sentence of 2nd bullet, combine

        with previous occurrence (remove redundancy).

Jonathan:  Section (2) refers to requirements by number when the reqs
           an ULIST. Oops.
ACTION: Media Type editor to make requirements an OLIST.

Jonathan:  Section 3 defines a binary EII as defining additional infoset

           props: These are not additional infoset props.. they are more

           constraints on current ones. 
Glen:      Offers wording: "A binary EII is an EII defined as follows
ACTION: Media Type editor to clarify binary EII term, a la "a binary EII
        an EII defined as follows"

(More discussion about the document wording .. low level editorial type

Consensus to change examples to have one example which uses the full
syntax instead of the authoring convenience types.

ACTION: Media Type editor to have at least one example which uses the
        syntax instead of the convenience types.

Jonathan: remove ":" from 2nd para of 3.1 after "both"
Straw poll on whether to remove colon?
Nahh, we will remove it ...
ACTION: Media Type editor to remove colon from 2nd para of 3.1.

Anish:   Would like to add an example of a schema and an instance doc
Sanjiva: Appendix for schema definition: use "xmlmime" as the namespace 
         prefix instead of "tns".
Jonathan formally appoints Anish as editor of the spec from the wsdl wg
too. He is already the editor from the xmlp group.
He accepts it with a lot of worry about the additional work thereby

Jonathan: Next steps: update the document, declare as WSDL LC and ask
          dual personality editor to take it to XMLP to agree to LC
          If they agree the doc goes to LC and thence to a Note.

15:00 Last Call issues (cont.)

Issue LC29b
 Skipped till glen is back.

Issue 29c

Hugo:     There is not resonable default for HTTP binding?
Jonathan: Do exactly what we did for the previous issue (LC29a)?
[hugo:    It could be 400 or 500 depending on whether it is a client 
          or service error.]
ACTION:   Editors to record same solution for Issue 29C as the
          for why faults are not given a default binding
discussion (again) whether that was the right decision ...
Roberto:  Suggests that we could just always use 500 as the status code 
          because app level faults (those that are described in WSDL) 
          fault because of app problems on the server: meaning 500
RESOLUTION: We will resolve this issue as before (no default for WSDL 
ACTION: Editors to implement a fix for LC29c similar to the fix for

Roberto has raised a LC issue against us whether to allow setting the
"reason phrase" for HTTP 500/400 etc. responses.

Issue 29b:
Glen says Mark got it wrong - Glen will send an email explaining to Mark
ACTION: Glen to send email to Mark
ACTION: Glen to write an ACTION item to implement this ACTION item.
[Marsh: RESOLUTION: LC29b closed, no action.]

Issue 29d
Skip until DaveO returns

Issue 29e:

The spec already says what happens if element is not there. We will
clarify that nil-valued elems will result in the empty string.
Discussion about how our current binding rules (which says that if the
element is missing then its a fault) doesn't support the case of
elements defined with minOccurs=0
[pauld:    An area we see lots of implementations issues is with 
           combinations of minOccurs=0 and nillable=true]
Jonathan:  For the case of URI construction, it seems to make sense to 
           say nil values (instance data that has xsi:nil=true on it) 
           result in the empty string being created
[pauld:    Schema spec has been open to interpretation here:
Lots of discussion about whether we are being schema-correct
Straw poll
option1: nils are treated as empty strings for purpose of URI 
         construction (including param replacemetn)
option2: outlaw nillable elements and hang them if they appear in 
         schemas that are going to be used in http bindings
no vote taken .. more discussion happenin'

Proposed compromise: instead of disallowing nillable types, we say that
its an error for instance documents to have elements with xsi:nil=true
[Roberto: in the first bullet point of]
Any objection for this compromise?
nope; accepted
RESOLUTION: It is an error for instance documents to have elements with
ACTION: Editors to add as 1st bullet of that it is an error for 
        instance documents to have elements with xsi:nil=true.

Tom:      Proposes the same solution for
Roberto:  Suggests that for automatically dropped parameters its better 
          to silently omit it .. 
Tom convinced Roberto that its better to be an error because there's a
diff between missing values and minoccurs=0 cases
[Roberto: promptly changed his mind since there is loss of information
in this case]
Consensus to make it an error to have nillable values when trying to
auto generate parameters
[Roberto: "uncited non-nil, non-list, possibly empty single values"]
[tomj:    Also change bullet items to be "Uncited elements with single 
          values (including empty values, but not nil)..."]
RESOULTION: It is an error to have nil values when trying to
ACTION:   Editors to change first bullet of section to say 
          "Uncited non-nil elements with a possibly empty single value 
          are serialized ..."
Close 29e with the above changes.

Issue 29f

Same resolution as before - nil values cause errors
RESOLUTION: close 29f with the same resolution as 29e (add bullet to
ACTION:   Jonathan to ask XForms folks to review WSDL.

Issue 29g

comment 1: deal with forward reference from 3.8 (ser formats) to 3.9
(styles). Classified as editorial.
comment 2 of 29g: we don't see a need to have a default style
ACTION: Jonathan to split 29g to two issues: first one to be tagged
editorial, 2nd (29h) to be closed as no need to do it.
RESOLUTION: 29h closed - no need.

Book-keeping of issues list
Proposal: mark 32, 34a, 35, 36, 39 and 40 as editorial and refer to
ACTION: Editors to implement editorial issues 29g, 32, 34a, 35, 36, 
        39 and 40 or come back to the WG with questions. 

[tomj: done for the day!]

17:00 Adjourn
Received on Saturday, 18 September 2004 00:43:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:44 UTC