See also: IRC log
<scribe> scribe: jeffm
agenda review
postpone WS-addressing WSDL LC discussion until tomorrow
aob -- none
RESOLUTION: approved w/o change minutes telecon 16 feb 2006
<Jonathan> 2005-10-20: Kendall DONE
<Jonathan> 2006-02-02: Jonathan DONE
2005-10-20 - Kendall - close
2006-02-16: Arthur/Tom - pending
<Arthur> i did my review
2006-02-16: Arthur/Tom - close
... Roberto - DONE
... Jonathan - 3 items - DONE
<Arthur> fyi - my ws-a wsdl binding comments are at http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0054.html
rechartering - new WSD Charter in front of AC -- waiting for a companies comments -- you know who you are
philippe: why are companies here not willing to commit to an implementation
glen: we are waiting for MS to commit
philippe: concerned that more progress is not being made
<GlenD> Philippe said "are you all just waiting for MS?" I said "We're expecting MS *not* to do it, so what's the point?" (half-smiley)
jmarsh: MS is not including support in v1 of WCF aka indigo
... there are some hooks
... for 3rd parties, will evaluate for future releases
alewis: tibco wasn't planning until after CR in any event; there are other factors - but can't really divulge those details of product plans
... need more evidence of maturity
... e.g. woden
philippe: did we just miss the market window? should we keep investing w3c resources
hugo: woden is ongoing; bluestem is interested and is doing an implementation
philippe: if we are still in CR in one year, what should we do?
... would like WG to produce a doc explaining why people should switch from wsdl 1.1 to wsdl 2.0
jmarsh: reality is amount of work to do wouldn't really justify holding a f2f here, except that it is piggy-backed on the Tech Plenary
alewis: less expectation is that spec will change radically
... this is a good thing -- tibco put impl plans on hold a year ago because the spec was changing to fast
jmarsh: formal work by arthur has contributed to feeling that spec is quite solid -- remaining issues really are focused on http binding
tom: "no one" (except tom/glen) here are actually working on the implementations
... havent seen a shift in WG attendance to implementors -- adobe looking at apache/woden
alewis: ASF looks "good enough" that a lot of companies will probably just pick it up
jmarsh: CR 2 purposes - make sure spec is technically correct -- 2nd is this spec important enough to industry to warrant moving to REC
... think spec is very solid, so really the issue is whether there is/will be enough industry interest
... not clear that impl experience will be sufficient by sept.
... is a year enough -- maybe we should have a 2 yr CR -- should we put the group "to sleep", disband, etc.
... anticipate once RDF is done, not much to do
hugo: people should reply to the call for review
... response is team confidential -- would appreciate an indication that the WG matters, or not
jeffm: why not put the WG into a quiescent/dormant mode -- infrequent calls when there are issues - and wait for another implementations
philippe: technically process doesn't require 2 impls, but the Director has to be satisfied :-) and he has set the bar at 2 impls
jmarsh: thinks this was fun :-)
... we can make sure that the one impl is high quality, and have good test suites -- will make it much easier for folks to do additional impls
... will discuss woden status in more detail tomorrow
glen: need more than just woden -- also need axis2
... i.e. need something that does the soap piece too
jmarsh: possibly talk about a test suite impl-fest in may/june timeframe
glen: notes such an event also forces debugging the test suite
expected schedule RDF meeting
jacek: work ongoing -- no mapping tables yet - will have doc that incorporates issue resolutions, and example, and partial xslt style sheet (no official standing)
... not many issues
... mapping tables production are essentially routine technical work that is just taking a while to get resources to complete
... if the work is not done by end of march, then that would be a good indication that there really is not enough organizational interest in pursuing the rdf work
jmarsh: once that work is done, LC period for at least 6 weeks
heartbeat:
hugo: WG needs to a pub at least every 3 months for every deliverable -- even if it is only to state that no work has occurred
... reads from the tablets -- .errr Process
... notes the Process really only says "SHOULD"
alewis: CR published jan 6, not very many chgs -- mostly editorial -- but chgs for http binding may require a new LC
... notes assertions may provide a good reason to re-publish
jmarsh: any reason not to republish once we get editorial, assertions, and issue resolutions done
... part 0, 1, possibly part 2 which could be split
RESOLUTION: wait until assertions are done and then republish (satisfying heartbeat requirement) - no objections
... close issue 107 -- no action
break 20 minutes
<Jonathan> resuming
jmarsh: at one time TR/soap pointed to the SOAP 1.1 Note
... people assumed that would be a stable uri to the 1.1 Note, but of course it was updated to be the SOAP 1.2 uri
... so we will have a similar question/issue for WSDL
hugo: TR/<shortname> always points to the latest version
... ended up having TR/soap point to a "cover page" which has links to both soap 1.1 and soap 1.2 docs
... of course this did introduce some "issues" for docs which did not point at a "specific/dated" version
... Question to WSDL WG for opinion on either chging tr/wsdl to point to a)cover page b)current version which would be wsdl 2.0
tom: in favor (at maximum) changing to cover page
anish: problem is exactly what soap faced
... compromise with cover page for soap was a good one, we should do the smae thing for wsdl
hugo: options 1)chg to latest 2)chg to cover page 3)leave it at wsdl 1.1 4)no opinion
anish: seems like another piece of the problem is that w3c chose wsdl2 rather than wsdl as the shortname
jeffm: suggests that WG adopt 2) chg to cover page as its advice to W3C
jmarsh: majority prefers cover page solution
tonyr: suggests that it might be a good idea for the W3C to create TR/wsdl11 which will point at the wsdl 1.1 Note
http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR007
proposed resolution from roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0016.html
glen: really says update the assertion list to capture the must not and (the real change) correct the mistaken attr ref to be an element
<Arthur> in <property> constraint is a child element, not an attribute
RESOLUTION: accept Roberto's proposed resolution - unan
hugo: raised the issue -- prob soap 1.1 allows an empty string, but we use an URI which doesn't
... therefore we should allow an empty str in addition to absolute uri
asir: its an optional prop - in soap 1.2 maps to not there, in soap 1.1 it maps to ""
... in soap 1.2 "" is not allowed
tom: should be able to specify "" as soap action
alewis: it is illegal to have "" as soap action in soap 1.2
hugo: started a wiki which would be a good place to put a description of the various actions in soap, wsdl, media types, etc.
jmarsh: certainly should clarify in section 2.3 make clear that "" is allowed
<charlton> hugo, would this be a good place to put a WSDL 2.0 FAQ?
<hugo> Web services wiki: http://esw.w3.org/topic/WebServices
<hugo> charlton, yes, that would be great!
jmarsh: clarify quoted-string by calling quoted empty string ("")
<Jonathan> quoted empty string value ("")
RESOLUTION: adopt proposal to add clarification to say quoted empty string value ("") - unan
RESOLUTION: accept proposal - unan
semantics of import
wsdl: import to be specific
alweis: do we need to as specific about include as import?
<asir> here is the tail end of this thread
<asir> http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0026.html
alewis: propose close no action because assertion is adequately expressed in the required namesapce attribute
<hugo> ohoh, we don't have RRSAgent...
<JacekK> ack
oops
jmarsh: include MUST be derefencerable, import does not HAVE to be
jacek: observes the current text is technically correct, but re-wording the assertion might make it clearer
<jeffm> jmarsh: include MUST be derefencerable, import does not HAVE to be
<jeffm> jacek: observes the current text is technically correct, but re-wording the assertion might make it clearer
<jeffm> RESOLUTION: close by accepting the text that is in the editor's draft in section 4.2.1 (2nd must in last sentence)
<jeffm> break for lunch 90 minutes
<jeffm> after lunch we will do the 2 http issues, including whether or not yank it
<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0050.html
<scribe> Scribe: anish
Hugo: the WSDL architechture is
not build towards HTTP, but it is pretty nice.
... there are problems. The context has changed. There is
WADL.
... Mark finding issues is a shame as we have not received
reviews from the right people. I have conflicting feelings
about it.
... I don't think throwing it away is the right thing. But not
sure if the right people are going to use this.
JM: we can always respond, if this tool does not do what u want, use a different tool
Hugo: I think Mark has some good
points
... We have to see if it gets implemented.
... we have done some good work and we should fix any bugs
JM: does Woden support/has done work for HTTP binding
Arthur: all the bindings in the
spec should be supported in the API and validator
... but Woden does not support it, it is upto Axis 2 to do
that
Glen: I don't know of any
specific plans in Axis 2 at this point to do this
... it is possible that it happens
Arthur: we should try to hook-up
with AJAX/PHP folks
... there is an Apache project starting up about AJAX
JM: what i'm hearing is that the impl. status of HTTP binding is not much worse than the rest of the spec.
<charlton> HTTP Binding is far more suitable to REST-style services - agree that we need to have such RESTful technologies look at how we've written the HTTP Binding
Hugo: I would approach this comment is to address the comments. It should be easy to address those
Amy: the commentary on the composition of the WG -- it is nonsense
Hugo: we could have a preface in the HTTP binding that says -- we can't describe the Web with this binding, but a certain class of application.
JM: if we get 2 impl. of rest of the spec and soap binding, what do we do then? If we pull it out, do we have to go to LC?
Hugo: it is completely
optional.
... we could make it a separate document if that happens --
that is a possibility
JM: i would like to enum all our
options
... a) fix the problems and leave it in there
... b) carve it out, looked at this during last f2f and decided
to leave it in
... (some attributes that are common to SOAP binding)
Asir: there is http:location
Jonathan: b1) keep it in CR
... b2) mark it at risk
hugo: procedurally do a tiny LC
tony: i think hugo is taking the timing issue too lightly
hugo: we don't have to worry about impl. having to redo their implementation
jonathan: any thoughts on the options?
Charlton: option (a) seems reasonable
Jonathan: other option is to mark it at risk
tony: marking it at risk is a cheap operation
<charlton> lowest impact option i think is to address the comments and leave it in there
Jacek: this could be a self-fulfiling prophecy
Jonathan: if we mark it at risk, what do we do with the http:location?
Tom: just make it go away
<discussion on WADL>
Glen: does Mark mention WADL?
Amy: he does mention it
Tony: i honestly think there is no harm in marking it at risk.
Hugo: if no one implements then we have an answer, if there are implementations then we have that answer
JM: Mark was a member of the WG, he could have pointed out the bugs then
Hugo: putting in a warning about inability to express every HTTP application might make him happy
<discussion on HTTP operations>
<charlton> Still, adding the warning and addressing the comments seems the easiest path
Jonathan: i detect a lack of enthusiasm
Amy: if soap binding depends on it, then marking it at risk may be an issue
Jonathan: the syntax would change
-- different namespace
... for http:location
Amy: it is sensible to have the
location in 'http' rather then 'soap'
... as other bindings show up, there are going to have some
form of addressing syntax
... i don't see a clean way to do that, unless we create a
minimal http binding which says: http binding and that's it
Tony: is our soap binding independent of http. What happens if I use SMTP
Amy: our binding is explicitly
for soap over http, but we don't prevent someone from using it
for smtp
... they will have define it
<discussion on how this works>
amy: we could change it to have soap binding have its own addressing mechanism, but that reopens some questions
glen: i don't think we need to do that
amy: we resolved these issues and
were hard fought. Changing it now may change the meaning
slightly
... the question of whether it (location) is optional, whether
it can contain an empty string, whether it is a locator or an
identifier etc
... changing it makes me nervous
... as soon as you move it from http to soap, the formally
closed issues may have to be reopened
<charlton> It doesn't seem as low risk to label it as "at risk"
asir: the location seems to be an independent piece
Amy: we could publish an http binding with just a 'location'
asir: what changes?
Amy: it makes soap over http the only valid binding
Glen: we have an error in the soap binding
<GlenD> http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/#soap-protocol
glen: what we mean to say that the underlying protocol uri is a soap binding uri and not a uri to the wsdl binding component
amy: we should fix that, open an issue
<scribe> ACTION: Glen to open an issue around WSDL binding component issue [recorded in http://www.w3.org/2006/02/27-ws-desc-minutes.html#action01]
Jonathan reads the description of the issue about section 6.4
Jonathan: it is about the http
version
... is the obvious solution to strike section 6.4?
amy: there is a comment in this issue suggesting that the attribute/property is inappropriately specified -- the tranfer-coding
<discussion on the version property>
tom: it doesn't seem like a valid subissue
jacek: lets not get hung up on
Mark's style
... we used to have http status reason in there. It is totally
useless. We dropped it
... we could drop this one too, same reasoning. We didn't think
about it much and put it there
... HTTP version can be negotiated
... the Web seems to work quite well, without this
Tom: that requires a round trip to figure out the http version, this seems like a good optimization
Jonathan: the default is 1.1
<charlton> This is required information
RFC 2145: Use and Interpretation of HTTP Version Numbers
<more discussion on what 2145 says and how http versioning works>
tom: i can support getting rid of it
<charlton> RFC 2145 infers that HTTP version is specified by the client which is negotiated at the server
amy: why not make it
optional?
... less change
... and defaulting to http 1.1
jonathan: that is what is the current status
<discussion on defauting the version and requireness>
Tom: this is giving the http version of the server, this is an optimization, but willing to give it up to fit things better
Glen: second that
amy: i could see us dropping it
Jonathan: in favor of removing section 6.4?
in favor: 6
no one objects
RESOLUTION: remove section 6.4 and associated editorial work
Mark's comment: - Section 6.6 constrains the data model of HTTP header field-values
to XML Schema simple types. This is an unnecessary and crippling
restriction; while those who are looking at the Web through a Web
Services toolkit may not mind, it's bad for the rest of the Web.
Amy: http headers are string
anish: we could get back to him and saying we think simple types work, what do you suggest
glen: yes
jonathan: instead of asking him, can we provisionally reject it?
Glen: yes. we can explain that we discussed it and we don't see the problem
RESOLUTION: we'll reject that particular comment, not make any change. It is not clear what other types Mark thinks are appropriate. This is not a general http header description language
Next subcomment: "Section 6.6.6 puts all HTTP headers in a WSDL-specific namespace,
thereby fracturing it from other efforts to uniquely identify HTTP
headers.
"
Jacek: there is a header component and a header name, which are different
Jonathan: he wants the http header component to uniquely identify http header names
amy: we adopt Jacek explanation
Jacek: what we identify here is components as opposed to header, we use the restriction of wsdl which says that one component per http header and we use this restriction to identify the component with the header name but we do not identify the header
RESOLUTION: adopt jacek's explanation (above)
next subissue: "Section 6.9 specifies a mechanism for advertising transfer coding
support, even though this is a hop-by-hop and dynamically negotiated
facility. If an intermediary is interposed, this information will
become useless and potentially harmful.
"
<JacekK> and the component gives a value, so we identify the "binding from the name to the value"
anish: this issue is similar to the version issue -- this is an optimization, treat it like the version -- be consistent
Desire to drop this in the room
next subissue: "- Section 6.10 encourages the use of cookies, which makes HTTP
interactions stateful, thereby losing substantial benefits of the Web.
amy: if all we are doing is providing support then we should just reject the comment
hugo: i'm pretty sure daveo will scream if we drop it
Jonathan: since daveo is in the room lets discuss Mark's comment (going back to version)
Jonathan sumarizes the comment on version and the WG discussion/tentative resolution
daveo: http is a description
protocol
... from wsdl-land one can describe things statically
jonathan: there is also
transfer-coding which is hop-by-hop
... this damages the abilities to describe it in wsdl
glen: it is an optimization
daveo: so is auhentication, but it is nice to know in advance
amy: things like authentication are independent of intermediaries, whereas the other can change with http intermediaries
<discussion of version and tranfer-encoding headers and its utility in description>
jacek: daveo raised a valid pt. that when this optimization is used in wsdl, it may result in sub-optimal usage. We have an optimization for a minor set of usecases and in this set there is another minor set of usecases where things are suboptimal
daveo: we agree that an intermediary may make this information useless, however the % of time that this info is useful is a worthwhile and not harmful
amy: if Mark could specify what fashion this is harmful ...
RESOLUTION: drop version, keep transfer-encoding
daveo: there is no warning from w3c about use of cookies
hugo: i dont think use of cookies is a good thing, i'm reiterating my position, if nobodies position has changed then lets move
RESOLUTION: no action on cookie issue
<scribe> new subissue: "Section six fails to take into account more complete and mature
efforts surrounding HTTP, such as WebDAV (e.g., the property model,
WebDAV ACLs, collections), making it difficult to accommodate this
work later.
"
hugo: you can use extensibility
RESOLUTION: not do anything about WebDAV, we have extensiblity or a separate binding, or use WADL
<charlton> DaveO posited how many people have brought up WADL on the list in the last few months
jonathan: since this was cc'ed to TAG, we should craft a good response to this
<scribe> ACTION: Tony to respond to Mark's comment (issue CR011) [recorded in http://www.w3.org/2006/02/27-ws-desc-minutes.html#action02]
<break>
<back from break>
Jonathan: from previous telcon --
the element of the proposal was to loosen restriction on local
element children
... they are matched in order
amy: worth noting that SPARQL is using HTTP binding and dropping it may be a problem
tony: will this take us to LC?
Jonathan: any other solution we want to consider?
hugo: in order to fix this we
need to change 2 bullets in IRI style
... don't know if it will take us to LC
... if we remove maxOccurs is 3rd bullet and remove 6th bullet
+ some text -- will resolve the issue
amy: can we get proposed text
jonathan: we also need to remove
the sentence "An element MUST NOT be cited ..." in section
6.8.1.1
... does anybody think this will require us to go to LC
hugo: it is a minor change that we need to get right
amy: we should take into account the needs and usecases of people who are using this stuff
tony: does wsdl describe fixed size array or a var. size array?
jonathan: not really. The question is if there isn't enuf data to fill you array what do I do?
amy: in that case we say that
this is an error
... in bullet 3 we need to strike the entire clause about
minOccurs/maxOccurs having a value of 0 or 1
<general head-nodding about that>
Jonathan: elements of the
solution are:
... 1) remove minOccurs/maxOccurs
... 2) remove restriction on duplicate element names
... 3) removing the restriction in 6.1.1 (about the element
MUST NOT be cited ...)
... 4) add some text matching up tokens with data in
order
... 5) more tokens than data is a fatal error
<scribe> ACTION: Hugo to write up text that captures the above points by tomorrow [recorded in http://www.w3.org/2006/02/27-ws-desc-minutes.html#action03]
[chair] Hugo presented this and we agreed.
RESOLUTION: Accept proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0061.html
Jonathan: any objections to providing the text to the editors to resolve this issue
no objections
Jonathan decrees that this will be CR014
<Jonathan> http://lists.w3.org/Archives/Public/www-ws-desc/2006Feb/0058.html
amy: i don't think this is an issue
jonathan: this is a whitespace
separated list
... proposed resolution -- add in section 2.16 that list means
whitespace separated "things"
RESOLUTION: resolution of that issue as proposed by Jonathan
The issue above will be CR15
Jonathan: this will be issue
CR16
... This looks like a feature request
<discussion on this email>