David Booth, W3C Allen Brookes, Rogue Wave Software Roberto Chinnici, Sun Microsystems Ugo Corda, SeeBeyond Glen Daniels, Sonic Software Youenn Fablet, Canon Hugo Haas, W3C Anish Karmarkar, Oracle Amelia Lewis, TIBCO Kevin Canyang Liu, SAP Jonathan Marsh, Chair/Microsoft David Orchard, BEA Systems Bijan Parsia, University of Maryland MIND Lab Arthur Ryman, IBM Asir Vedamuthu, webMethods Umit Yalcinalp, SAP Prasad Yendluri, webMethods, Inc.
Paul Downey, British Telecommunications Tom Jordahl, Macromedia Dale Moberg, Cyclone Commerce
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-30: Arthur to add Z notation to Part 1. 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 188.8.131.52 of Part 1. (subsumed by LC21 resolution?) DONE 2004-10-21: Glen to respond to Tim Ewald re: LC9. PENDING 2004-11-09: DBooth and roberto to describe option 2 (remove definition of processor conformance, write up clear guidelines to developers) (LC5f) PENDING 2004-11-09: DaveO to work on text for option 3 (redefining conformance in terms of building the component model) (LC5f) PENDING 2004-11-09: DaveO will recast the @compatibleWith proposal using an extension namespace. (LC54) PENDING 2004-11-10: Sanjiva to write the rationale for rejecting LC75a PENDING 2004-11-10: Glen will post an e-mail describing the compromise proposal on formal objections. PENDING 2004-11-10: Editor remove ambiguity if it exists PENDING 2004-11-10: Sanjiva will write up this proposal and email it to the list as a response to the objection. PENDING 2004-11-11: Anish to propose additions to the test suite for the purpose of interoperability testing. PENDING 2004-11-11: Editors of part 2 and 3 to add text about WSDLMEP and SOAP mep mapping that points to section 2.3 of part 3 (LC48b) DONE [.4] 2004-11-11: Umit to check on operation@style (LC61a) PENDING 2004-11-18: DBooth to propose text to clarify that a service must implement everything in its description. PENDING 2004-11-18: Mini-task force to propose one or two proposals for the group for LC5f. PENDING 2004-12-02: DBooth to draft note clarifying that (a) optional extension can change the semantics; and (b) that if semantics are going to change at runtime, it should be indicated in the WSDL PENDING 2004-12-03: Glen and Asir to help craft the specfic text for the editors. PENDING 2004-12-03: Glen to send example on feature stuff for primer PENDING 2004-12-03: Hugo or JMarsh to write up schema group remarks DONE 2004-12-16: Marsh to follow up on telcon for Australia FTF. DONE [.3] 2004-12-16: Marsh to publish spreadsheet with Good Standing calculations. DONE 2004-12-16: Primer editors to add explanatory text and refer to the latest editor's copy of the spec. DONE 2004-12-16: Primer editors to check examples and make sure they are consistent with the latest wsdl2.0 schema. PENDING 2004-12-16: Part 3 Editors to update the HTTP binding with one of the above versions of text [.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/Member/w3c-ws-desc/2004Dec/0021.html [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Dec/0038.html
Thompson's W3C membership has expired.
Jeff Schlimmer replaced by Jonathan Marsh
Next f2f is right after the plenary
Important to attend telcons to remain in "good standing".
Please contact Jonathan if you tried to dialin and could not, because of issues with Zakim.
JMarsh looking for reviewers for WS-CDL.
Possible issues: features, meps (different interpretation), etc.
All issues listed in agenda proposed as editorial
Umit has proposed a different order for looking at the issues
Commentator asks more liberty in specifying the expected media-type, for example "xml" would match "application/xml" and "svg+xml".
Umit thinks would provide more than what we have (intended to provide).
Umit et al. have made 3 proposals and propose to adopt proposal 2.
jmarsh: any questions or other
... any objection?
... proposal accepted
a. "Accept" not allowed
b. accept-extensions (was) not possible. Has now become possible.
<Marsh> ACTION: MTD editors implement proposal 2 for issue 260, reject other part of the comment.
c. conflict between schema type (xs:string) and RFC2616 (octects allowed)
For the latter, could change type to base64 or exclude quoted octets, or even not use RFC2616
mnot and arthur were in favor of the latter.
jmarsh points out we chose the current approach because of the difficulty of writing the correspoding schema.
anish: concern was about interop.
jmarsh: so 2616 allows some code
points not allowed in XML?
... so limited to a subset?
anish: have to specify how raw octets
can be encoded in XML
... they use quotes to delimit octet strings
roberto: agree with Jonathan, certain quotations will be invalid because of XML
jmarsh: and fewer with XML 1.1
roberto: backslash-quote will just be seen as 2 characters in XML, not an issue
anish: what about, for example, characters 129 and 133?
umit: how common are octects used in practice?
anish: same problem for content-type
amy: content-type is defined as for
MIME, so character set is restricted to ASCII (literally), so is
... in MIME, if putting non ASCII representable string, (probably) have to use base64
<anish> in rfc2045 the parameter value can be a 'token' or 'quoted-string'
jmarsh: although pointing to RFC2616,
since we are XML, the attribute value would be restricted to a
subset supported by XML
... so a little different from proposal c.3, just eliminate some characters, not all
... cannot represent raw octets that are not allowed in XML
... the XML rule would subset RFC2616
anish: by quote-octet, you mean what is inside the quote to be interpreted as octets?
<alewis> "quoted-string" in 2045 *still* excludes control characters and characters with the high bit set.
jmarsh: maybe we agree
... if you give me a list of strings compatible with 2616, and i cutandpaste in XML, only certain will work
<anish> thx amy i saw that, it is actually defined in rfc 822
<anish> but the production rules for 2616 are different from that of 2045
amy discussed how base64 is also used
agreement finally to use c.3
jmarsh/umit: not yet available, so maybe should wait until schema does the work first
<anish> IIRC (I was not part of the WG then) the wsd wg looked at a whole bunch of options and rejected NOTATIONS
<anish> i think it was david or philippe who did a evaluation of all the possible options
<dbooth> I don't think it was me.
<anish> i'll try to dig it up
<anish> i don't understand it either
anish: should ask Henry to come up with examples
umit: do we really have time to change the design completely
jmarsh: gains: special purpose constructs
umit: but inventing brand new names
asir: benefit: don't need a production rule
jmarsh: but would loose the q parameter
umit: and the parameter for the individual mediatype
jmarsh: would like to see examples from Henry, and maybe we could send him our own examples
asir: ask for a dozen mediatype example
jmarsh: feed him the examples we have allready, if any
<Marsh> RESOLUTION: Reject Henry's first proposal for 271
<Marsh> ACTION: Umit to respond to Henry asking for lots of examples on Notation solution.
jmarsh: How to distinguish between
hexBinary and base64Binary in the absence of XML schema?
... the answer is you cannot; but should you be supposed to?
umit: even if use @xsi:type?
anish: MTOM finds out because content-type of envelope is application/mtom
jmarsh: could add note saying content-type is not sufficient, information to be provided via other mechanism, for example xsi:type
umit: was my suggestion
anish: fine solution. yet another is to get rid of hexbinary, only keep binary
umit: what happens if you use mtom?
anish: mtom deals specifically with base64binary
jmarsh: consensus to add note as
... no objection
RESOLUTION: solve 266 by adding note as suggested by Jonathan above
<scribe> ACTION: Editors to add note "could add note saying content-type is not sufficient, information to be provided via other mechanism, for example xsi:type"
umit: taking Larry seriously, but would like him to understand we are not defining a protocol
jmarsh: also says that "image/*" not useful because of the variety of image types not implemented
umit: has to be able to use a range, if, for example, support jpeg and gif
jmarsh: say I implement all possible
image types, but suddendly someone adds one?
... so respond as : "not a protocol; if other issues, please post them separately"
asir: at some point there is a mapping done
umit: but not dynamic, you know in
... "*" is an extensibility point. It is up to the service to make sure it can actually handle it.
jmarsh: suggests respond as umit suggested (and see what happens). Not sure what solution he is suggesting
asir: RFC2533 is pointed out
umit: but not accepted at all, so no fruitful avenue to pursue
jmarsh: not recommendation track document; ok to go with average, understandable solution
umit: should we add more than what's in my original email?
jmarsh: yes: not dynamic, other
solutions equally bad, not recommendation track, if problems happy
to consider those
... objections to reject?
RESOLUTION: Reject issue with reasonning above
<scribe> ACTION: Umit? to respond to Larry, "not dynamic, other solutions equally bad, not recommendation track, if problems happy to consider those"
umit: suggest people read reasonning for classifying issues as editorial