See also: IRC log
Chair reviewed the agenda
Minutes were posted for last week, Chair called for corrections.
RESOLUTION: Last minutes and the F2F minures from 11/8 were approved
Issues 17 & 16, 31, 08 are done
Send message to Chair if remote participation in Redmond F2F is desired
Jan 17-19 will be in Melbourne
Logistics and registration will be out in the next few days
April F2F will be around April 15. Meeting after that would be in early June.
Marc: ready to publish first working draft
Chair: Working drafts will be reviewed prior to publication
Discussions on the list this week, be concise and clear, goal is to vote for working draft next week.
Marc: There are minor editorial changes remaining to make
Chair: Editors, if changes are made this week, please publish summary of changes to the list
Chair: Shall XML schema be used to describe the spec? Chair asked if there are any objections
... There were no objections.
RESOLUTION: XML Schema will be used to describe the specification where appropriate
Discussion wrt XML 1.1 or pseudo schema or text for normative description
Jonathan: proposal to drop xml 1.1 for use in the normative description, Rutt agrees
Rutt: suggests that schema and text could both be normative but would be difficult to sync.
<rsalz> it's actuall *3* things to keep in sync: prose, xsd, psuedo-schema
Hugo: proposed that the schema be normative for 1.0
<anish> could we just have prose and xml schema for 1.0?
<rsalz> yes, please. :)
<anish> iirc, xmlp decided against xml 1.1 as soap 1.2 became a rec before xml 1.1 and SOAP 1.2 already had schema as normative
mnot: straw poll to restrict use to xml 1.0
<Marsh> +1 for Microsoft
+1 for Hitachi
<rsalz> +1 for datapower
<anish> i'm sypathetic to the complexity issue (look at wsdl), but perhaps preventing xml 1.1 may be going to far
<Greg> +1 for IBM
<RebeccaB> +1 for IONA
<mpeel> +1 for Novell
<TomRutt> +1 Fujitsu
<marc> +1 for Sun
<stevewinklr> +1 SAP
<TomRutt> How about restricting to the soap binding?
Straw poll was taken, and decision was made to restrict use to XML 1.0
RESOLUTION: WS-Addressing's use of XML will be restricted to XML 1.0
<scribe> ACTION: Rich to begin work on schema
<pauld> existing ws-addressing schema: http://schemas.xmlsoap.org/ws/2004/08/addressing
Assigned to Rebecca, Rebecca reviews verbally
Rebecca proposes adding one property to the epr where the complete wsdl may be located
<vinoski> +q
Chair: discussion to continue on this topic via the list
<Zakim> Marsh, you wanted to ask about interaction with [service-port] and/or [selected port type]
<TomRutt> +1 steve
anish: concern that if we go down this path, it may have implication with other issues.
Chair: continue discussion on the list
hugo: discussion is around uri cum reference properties exacerbating problems that exist with uris as they stand
... simplicity argument is that reference properties are known to the provider and are not part of the externally usable (to the service provider) address
... disadvantage is that to secure a uri, then it must be secured in its entirety
hugo: Web arch says that resources are uniquely identified by uris.
... not ready to make a conclusion
Chair: wants to kep it moving along
<stevewinklr> +1 to clear terminology
Rutt: in order to reconcile spec with web architecture, then it will be necessary to refine the name to be something that will help foster understanding
<anish> +1 to marc
Marc: analagy has been made that reference parameters are a lot like cookies, and that cookies are not used for addressing
Chair: from the web architecture, cookies are broken, and that they are used to carry addressing information (as well as other info)
Chair: gudge not online
<rsalz> away away from my desk for 30 minutes, in case you care
<anish> +1 to hugo, this is tied with the issue currently being discussed in WSDL as to -- what is a node?
hugo: node is a logical entity that may be addressed uniquely
Chair: possibility is to accept the proposal and say that this is the list of starting point MEPS that will be covered
... asked for objection, none heard i003 is closed with gudge's proposal
and that MEPS covered will be part of our continuing discussions.
RESOLUTION: i003 is closed by accepting gudge's proposal for list of MEPs; supplied text will be starting point for further work.
Marc: Several questions arised related to the scope of reply-to
... and with which MEPs reply-to had what meaning.
... bigger issues need to be resolved prior to i028's resolition
Relates to semantics of Fault-to
Marc: ? must we define the implications of the presence or absence of each of these for each MEP?
Chair: may be part of a larger issue which is conformance to each of the documents of the specifications
... will try to raise this issue this week.
Chair: propose closure to i012 with proposal rev 2 by paco.
<Chair> http://www.w3.org/mid/OF56AF0FA7.74E5CA56-ON85256F46.00761383-85256F47.0042B98B@us.ibm.com
Chair: hearing no objection, i012 is closed with proposal 2
RESOLUTION: i012 is closed with proposal 2
hugo: wsdl 1.1 and wsdl 2.0 descriptions may both exist. What would then be the interprety of the action property
Chair: going forward, we may consider splitting hugo's sub-issue of default actions and closing the rest
marc: if action were optional, this issue would go away
anish: this is a bigger issue than action since we have reference to wsdl in other areas
Chair: let us split this up and record this as a new issue, can we close the remainder of i019?
... asked for objections/ hearing none, i019 is closed with the carve-out of the new issue to be posted
RESOLUTION: i019 is closed by accepting Hugo's proposed changes, except for those relating to the default action.
hugo: we have a choice of making addressing ubiqutous, and we could request that address be defined in the soap bindings.
... addressing ought also to be represented in tools. In order to do this, one ought to define a soap 1.2 module
<anish> +1 to option #2
as well as a proposal to cover in WSDL 2.0
<marc> -infinity to option #1
<pauld> seems like ws-addressing is a good pilot for WSDL 2.0 extensibility .. so option#2
<GlenD> +1 to option 2
+1 to option 2
<GlenD> (it'll take an awful lot of +1's for option 1 to make up Marc's vote....:))
<anish> :-)
just calcualte the average vote in favor
Chair: WG will go forward with option 2.
Marsh: Believes issue needs more work concerning use over all versiosn of wsdl
... wsdl 1.2 offers one extension mechanism, 2.0 offers two. Believes debate would be meritotious as to which mechanism should be used.
Hugo: it was his intent to cover all of our bases in wdsl
Marsh: we could develop a proposal for the use of both extension models so that we could see the proposals side by side.
<scribe> ACTION: hugo: Will send another email with a refined proposal for i021 by Nov 26
Multiple ports in EPRs
Chair: (aside) new issue, pls get involved in new multiple port and EPR issue.
issue number to be assigned
<scribe> ACTION: anish: Nov 17 to explore the scope of the action defaults issue
return to i026
steve: Believe that a lot of services are accessible over multiple transports/protocols. What we are finding is that customers would like to re-use their legacy protocols.
trying to put together a true service reference with one construct. Alternative is presented to include optional information to the EPR so that all of its addressing capabilities could be specified
Additional alternative was described that the scribe missed completely
pls refer to email proposal for detail
steve: proposed that complete addressing information be included so that network operation to look up further addressing information would be unnecessary
<Zakim> Marsh, you wanted to ask where the boundary between these proposals and the whole WSDL is.
Chair: Is this isue complementary with i033?
steve: some applications have a lot of pre-configured knowledge of addressing situation, other applications have little pre-configured knowledge.
rutt: would reference properties be the same for these different situations?
<anish> if we go down this path -- then i would prefer option 1 over option 2
Chair: issue needs more seasoning.
Rutt: understanding of i001 will help us figure this out.
Rebecca: askes for activity re i023 on the list
<scribe> ACTION: anish send a mail to rebecca to start by 11/18