WS Description WG telcon

Marsh - Approval of minutes

Approved

--------------------------------------------------------------------
3.  Review of Action items [.1].

?         2005-07-21: pauld to write a proposal for a working group
                      report for requirements for schema evolution
                      following closure of LC124 
DONE [.7] 2005-09-22: Marsh will look at section 5.6 in relation to IRI,
                      due 2005-09-26. 
?         2005-09-26: Arthur to figure out how to treat built-in schema
                      types. (LC315), due 2005-10-06. 
?         2005-09-26: DaveO to draft a response and send to the WG.
                      (LC335), due 2005-10-06. 
?         2005-09-26: Arthur to draft above as a proposal to be able to
                      close this issue (LC344#5), due 2005-10-06. 
DONE [.6] 2005-09-26: Hugo to look at sections 4.2 & 4.3 of part2 and
                      see whether the first sentences (paragraphs) are
                      no-ops. (LC344#5), due 2005-10-06. 
DONE      2005-09-26: Roberto to change the order of the union in the
                      schema in 4.1.2 to match the order in the prose.
                      (LC344#5), due 2005-10-06. 
?         2005-09-26: Arthur to look for simplification options for
                      comment 12 of 344. (LC344#12), due 2005-10-06. 
?         2005-09-26: Jonathan to point this out when it gets
                      Implemented (LC344#13), due 2005-10-06. 
?         2005-09-26: Sanjiva and Roberto to investigate defaulting with 
                      interfaceless bindings (LC333), due 2005-10,06 
DONE [.3] 2005-10-06: Marsh to reopen registration, due 2005-10-06. 
DONE [.4] 2005-10-06: Marsh to Aput the Description issue on the 
                      issues list, due 2005-10-13. 
DONE [.4] 2005-10-06: Marsh to track .6 on issues list, due 2005-10-13. 
?         2005-10-06: Marsh to investigate LC301 re .NET scenarios, 
                      due 2005-10-13. 
DONE [.5] 2005-10-06: Hugo to review his LC304 proposal in light of 
                      the LC337 resolution, due 2005-10-13. 
?         2005-10-06: Charlton to augment Hugo's proposal with 
                      parameters for all serializations, and syntax 
                      for suppressing parameters, due 2005-10-13.

Current Editorial Action Items
?         2005-07-21: Arthur to add stable identifiers for each
                      assertion, due 2005-09-26.
?         2005-09-26: editors to fix the first paragraph of section 4 
                      ... does not make sense at all right now. 
                      (LC344#5), due 2005-10-06.
?         2005-09-26: Editors to add a sentence saying {address} is
                      optional because it could be defined by other 
                      means, such as an WS-A endpoint reference or maybe
                      the scenario does not require an address. 
                      (LC344#13), due 2005-10-06.
?         2005-09-26: Editors fix "Case Elements NOT cited" in 6.8.1.2
                      header to be "Case of elements NOT cited" (LC345),
                      due 2005-10-06. 

Note: Editorial AIs associated with LC issues recorded at [.2].

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/lc-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2005Oct/0008.html
[.4] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues-condensed.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0008.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0009.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2005Oct/0013.html

Marsh: Action Item Marsh: to look at section 5.6 in relation to IRI. Thinks fine as is.
... Hugo to look at sections 4.2 & 4.3 of part2 and

see whether the first sentences (paragraphs) are

no-ops. (LC344#5), due 2005-10-06

Marsh: done
... Roberto to change the order of the union in the

schema in 4.1.2 to match the order in the prose.

(LC344#5), due 2005-10-06.

<scribe> Done

Marsh skip over editorial action item

Marsh: Administrivia
... about 13, 14 people attending Bob's pre-meeting function
... RDS mapping. Hugo - ETA mapping tables - Last monday

Hugo: can't start until next week. Hopefully Bijan can send something by then and we can get started

Editorial issues

<Marsh> ACTION: Marsh to add RDF links to home page. [recorded in http://www.w3.org/2005/10/13-ws-desc-minutes.html#action01]

Hugo: coordination item on SPARQL
... They're in last call, heavy users of WSDL 2.0
... deadline is tomorrow

<pauld> volunteers

Marsh: Who would enjoy privilege of reviewing SPARQL draft?
... silence...

Pauld: volunteered

GlenD: will take a look at it but can't commit to review

pauld: will try for next week

ACTION: Paul and Glen to review SPARQL draft.

Hugo: ws i18n - have spec to review. describing extension using WSDL F&P
... 1st public working draft - looking for comments

<pauld> s/gelnnd/JelliedEels/

no volunteers to look at I18N spec...

<Marsh> s/s\/glend\/Gelnd\//s\/Gelnd\/GlenD\//

Marsh: no takers, huh?

TonyR "volunteers" to review I18N spec

ACTION: Tony to review I18N draft.

Issue 348 - minor errors in adjunct schema

scribe: misspelling of must understand
... etc.

Marsh: RESOLUTION: accept edits

Issue 349 - reformulate intro to section 2, part 2 (Predefined Message Exchange Patterns)

TonyR: problem is using term before it's defined

Sanjiva: drop definition of node, perhaps?

<uyalcina> +1 to Marsh

Marsh: swap first para for 1st 2 sentences of 2nd para
... RESOLUTION: issue closed

Issue 350

Marsh: RESOLUTION: accept proposal

Issue 351

Marsh: editors add missing namespace

RESOLUTION: editors add missing namespace

Issue 352: Bug in RPC Signature Extension Schema

Roberto: Why add attribute form since global item
... only one attribute in entire schema

RESOLUTION: close with no action

issues

Issue LC304: Definition of a IANA media type token

Marsh: syntax is clear but meaning of paramteres unclear

Hugo: can have list of media types, can use wild cards & media type params; clearly defines what an IANA token is
... haven't seen any text for proposal for 337
... still some things to define
... in past looked at relationship btwn value of serialtization & formats we were using
... concluded that we said use this type and apply all these rules. Now more freedom in values and serialization formats
... should still clarify wildcards
... still have 1 concern: we have extensibility point here. Anybody can define new serialization format. If come up with, say, serialization of RDF, nothing prevents somebody else from coming up with another serialization with same name

<JacekK> hugo: the other thing is that we enabled accept parameters, and we don't say what it means

<JacekK> hugo: we can say that if the parameters are there, the serialization format should specify what to do, if it doesn't, the parameters should be ignored

<JacekK> hugo: these two points should be addressed before we can close the issue

<JacekK> hugo: an example: we define how form-url-encoded works, but what if somebody else wants to define other serialization for this format?

<JacekK> Marsh: they can use a required extension

<JacekK> hugo: so serializations are defined on a first-come-first-define basis, if somebody wants to redefine, they can add required extension

<JacekK> Marsh: why would somebody want to do that anyway?

<JacekK> JacekK: so is the problem that it's hard to discover a description of a serialization format only based on the media type?

<JacekK> hugo: maybe URIs would have been better, but at this stage it's hard to change, and people are used to media types for serialization formats

<JacekK> hugo: if you just see the media type, you have no idea where to find the spec, or which one of multiple findees is the one to be used

<JacekK> Marsh: maybe this extensibility point is not really well thought through

<JacekK> Marsh: I thought it would be limited, but apparently anyone can extend it, according to what we say

<JacekK> Marsh: could we limit the media types to the ones we talk about plus any XML-based media types?

<JacekK> hugo: this would be an option

<JacekK> hugo: then what's the meaning for the wildcard?

<JacekK> Marsh: do we have usecases for non-XML media types besides the ones we described?

<JacekK> hugo: we don't have evidence, but it might exist

<JacekK> uyalcina: we introduced the capability to say we're sending jpeg in schema, wouldn't this drop it?

uyalcina: restrict return? don't want to send JPEG only

Marsh: have to describe output so have same problem

Sanjiva: can use same as MTOM

Marsh: can now serialize XML and use MTOM, right?
... How do I describe image return is jpeg?

Hugo: solving issue involves two paths: 1. extension point & good story about extensibility
... 2 closed set
... if extensibility, some kind of disctionary would allow you to express what xml serialization with url - what actually using is serialization format defined at URI
... don

't need to change syntax. If use IRIs lose params and wildcard capability

hugo: like to avoid it because it's a big change

'marsh: closed set in minimal change

uyalcina: current proposal is to use closed set. does it line up with schema? possible mismatch
... will put more restricytions on what you can do

Marsh: possibly have to list all formats
... root of problem is can't defer all details to media type

uyalcina: or say please use mtom and all probs go away

Marsh: just say SOAP

hugo: wants to see what feeling of group is

<sanjiva> can someone tell me why one can't use mtom with the http binding??

hugo: wonders is closed set does solve problem in 337
... silence...

<sanjiva> I have to admit I have no idea what this closed vs. open set business is

uyalcina: common use case to send pix

marsh: more and more we're coming up with http description language

<sanjiva> I don't see why one can't use the current binding to describe a service that simply returns a JPG: Define the response msg using URI style and define one child element tagged with xmime:contentType=image/jpg and serialize with mtom

dorchard: if we had http descr lang that would be great, but if have to trade off describning jpeg rather than getting wsdl spec done 2 weeks earlier, then schedule should reign

hugo: we must include big fat note about restrictions inherent with closed set

sanjiva: mtom rules discuss how to package xml

marsh: difference btwn way to send data in media type & reconstitute at other end vs. describing it

sanjiva: write xml schema using rpc style, wrapper elt, one child as xmi attr

marsh: describe struct using xml, wrap it in xmi envelope...
... inventing "non-xml media type schema"
... inventing new style to make it work

sanjiva: inventing new style good thing

ulyacina: two styles for http binding?

marsh: should compose ok
... would like to list a few options, get people to think more, write them up
... sanjiva - write up your proposal & send in email?
... another proposal to tighten up with closed set - someone volunteering to write up?

hugo: I'll take a look at it

<scribe> ACTION: sanjive to write up his proposal sanjiva to write up style-based generic mapping in to media type [recorded in http://www.w3.org/2005/10/13-ws-desc-minutes.html#action02]

<scribe> ACTION: Hugo to write up URI's describing serialization format architecting serialization format extensibility point [recorded in http://www.w3.org/2005/10/13-ws-desc-minutes.html#action03]

issue 345 - waiting on proposal

marsh: splitting out http binding - wait on discussing?
... issue 329 - we accepted capitaization of may, must, should
... 3) section 5 in the beginning (fourth para) points out how no defaults

are provided for faults so if an interface contains faults, it must be

bound explicitly. That's no longer true since we made code and subcodes

optional; that fourth paragraph from section 5 should be removed.

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0012.html

above is 319 resolution

marsh: let's see if we're ready to close 329

hugo: we do clarify that propoerty is not optional but now include 'any'
... is still optional that wsdl would specify fault code
... when attr not there in wsdl xml, prop gets 'any'

marsh: ready to accept proposal to remove 4th para from section 5?
... replace with something?

Jacek: just drop
... now we can default everything

RESOLUTION: close 329 as Jacek proposes in 3rd point of his proposal

issue 342 : Typos (Adjuncts)

http://www.w3.org/2002/ws/desc/5/lc-issues/#LC342

scribe: glen's proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0052.html

glend - finished at F2F

marsh: rewording of strange text

glend - maybe we didn't actually discuss this at F2F

<Marsh> "SOAP Modules are the means by which additional functionality (typically

<Marsh> implemented as SOAP headers on the wire) is added to the basic protocol

<Marsh> (see [SOAP 1.2 Part 1: Messaging Framework]). This binding extension

<Marsh> specification allows users to indicate which SOAP Modules are in use

<Marsh> across an entire binding, on a per operation basis or on a per message

<Marsh> basis."

<charlton> +1 to Glen's rephrasing

general agreement that it looks good

<jjm> +1

marsh: reads & interprets rewording

RESOLUTION: 342 closed with glend's proposal

issue 343: WSDL 2: binding defaults not component model properties?

<scribe> ... continued later

Issue LC344: LC ISSUE: Editorial points - skip over

Issue LC347: Interface definition

marsh: our issue list should be closed now
... reads 347 - redundant to declare fault inside interface

<uyalcina> +1 cwna

marsh: ask if anybody sees anything new in this?

<charlton> +1 to close

nobody sees anything new - close with no action, ship it!

RESOLUTION: close 347 with no action as redundant with previous issue

Issue 353: What is a valid WSDL component model?

marsh: any thoughts on how we define a "valid" wsdl 2.0 component model?
... have bunch of constraints reflect in z notation and definition of component model buried in there. any way to define conformance?

Asir: whatever constraints we have in z we have in text also

a wsdl 2.0 component model that conforms to all the normaitive constraints as defined in the spec

scribe: above is suggested wording