Web Services Description

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