Web Services Description

Present

 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.

Regrets

 Paul Downey, British Telecommunications
 Tom Jordahl, Macromedia
 Dale Moberg, Cyclone Commerce

Chair

JMarsh

Scribe

Jean-Jacques

Action Items

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 2.4.1.1 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

Admin

Lexmark resigning

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.

Bijan volunteers.

Possible issues: features, meps (different interpretation), etc.

MediaType description issues

All issues listed in agenda proposed as editorial

No dissent

Umit has proposed a different order for looking at the issues

ISSUE 260

<Marsh> http://www.w3.org/2002/ws/desc/2/06/issues.html#x260

<uyalcina> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0008.html

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.

260

jmarsh: any questions or other preferences?
... any objection?
... proposal accepted

ISSUE: 259

<uyalcina> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0009.html

Three subissues:

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 entirely compatible
... in MIME, if putting non ASCII representable string, (probably) have to use base64

<anish> http://www.ietf.org/rfc/rfc2045.txt

<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

ISSUE 272

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

umit volunteers

jmarsh: feed him the examples we have allready, if any

ISSUE 271

ISSUE 266

<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?

jmarsh: cannot

anish: mtom deals specifically with base64binary

jmarsh: consensus to add note as suggested above?
... 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"

ISSUE 268

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 advance
... "*" 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

<anish> http://www.ietf.org/rfc/rfc2533.txt

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

Adjourned