See also: IRC log
No changes to agenda
Agenda item 3: no changes requested. No objection to accepting minutes
RESOLUTION: minutes of 11/15 accepted
Last Action item is completed, Anish mailed out discussion in issue 23
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0460.html
<anish> few proposed changes: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0463.html
Chair asked if we can accept all three documents as working group drafts
<anish> note from rich: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0437.html
Chair: does anyone object to calling out use of xml schema 1.0 in specification?
chaiir: Rich is suggesting we use xml schema to describe our structures, and we are to limit use to xml 1.0
Chair: is there objection to adding editor's note to the documents?
Marc: is this a simple note stating that future versions will use xml 1.0 schema , but the pseudo schema will remain for now?
Chair: yes
Chair: there is no suggestion to replace all normative language with xml schema.
No objection to having editor's including note as suggested by Rich.
Chair: in all three docs
Marc: I suggest in one place only.
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0463.html
Chair: any objection to publishing three docs with added note?
Anish: message 463 in november has suggested changes. Some are editorial.
Chair: several agreed issue resolutions have not yet been applied to these three docs
Hugo: we need a status added to the document: "this is an input document which will undergo change"
Chair: would adding such text make people happier?
Anish: I would be happy with such text.
Marc: I would like some help on the wording.
Chair: Point to the issues list, stating future changes may be incorporated to resolve issues.
<anish> +1 to hugo's suggestion too
Jonathan: I like to state this is just an editorial reformatting, with no changes from the input doc.
Hugo: We should state we are expecting to republish a new version soon.
Chair: do we have enough for the editor's to work with?
No objection
RESOLUTION: No objection to publishing three Public Working Drafts, with note and the status text added.
Anish: what about my proposed edits?
<RebeccaB> Doesn't Hugo's statement cover Anish's proposed edits?
<anish> it covers #3
Chair: with the exception of number 2, these are editorial, does anyone object to letting the editors have discression for 1 2, and 4 from anish email
No objection
<RebeccaB> Ah - gotcha
Chair: when can we expect these to be published?
Hugo: there could be a publication moratorium, we could get them out after the AC meeting by the end of next week.
Chair: the email seems to be moving towards publishing a document to explain our use of reference props and parms
DaveO: There have been some requests to change my propsed text, (e.g. Paco)
Paco: I can send to the list my proposed changes soon
Chair: what do others think about the approach of publishing a document
Jonathan: there is a difference on writing a document to reach concensus, vs publishing the concensus.
Chair: we do not have concensus yet, on the fine points. However, working on the explanatory document will help us reach consensus.
DaveO: I view EPRs as identifiers. If everyone agrees, Paco can reflect this in his edits. We might take a quick straw poll on support for the general direction for a WG position.
Paco: we have to clearly state what these identifiers are identifying.
DaveO: do we have two issues: are EPRs identifiers, and if so what do they identify.
DaveO: the EPR minter decides what is identified.
Paco: we have to be clear about comparison of identifiers, etc. This is my main concern about approaching issue 1.
Discussion on equivalence vs comparision
Paco: we could define equivalence but stay away from identity.
DaveO: identity to determien metadata equivalence
Anish: example of replicas, they identify the same thing to the comon user, but the replication manager needs to distinguish them
Paco: if you try to conclude they are different things, you will be in error. That is why they are not identifiers.
DavidO:Identifies a combination of endpoint plus protocols to access that endpoint.
Hugo: the concepts of endpoint having different wsdl (different service or logical endpoint) ws other metadata, needs clarification.
Paco: you have to limit the assumptions on comparing these EPRs, that is why I am concerned about making them identifiers.
Anish: WSRF draft spec talks about EPRs identifying Web Service Resources.
Chair: can Paco come up with a proposal for this, to discuss at the Face to face. Recasting how we talk about reference properties. Can you do this by Dec 1.
Paco: no problem to have it by Dec 1.
<anish> ACTION: paco to make a proposal for issue 001 by dec 1
<scribe> ACTION: Paco make proposal for issue 1 by Dec 1.
<Zakim> hugo, you wanted to talk about current debate and strategy before moving on to another issue
Hugo: we have reached a point where the same arguments, with same answers, are being repeated over and over.
... what is missing is a use case which would use both ref props and ref parms, to demonstrate the motivations and benefits in EPRs. Dave told me he is working on such a use case.
... we should also try to make progress on the other approach for discussion at the f2f.
DaveO: I send email to the group today stating that a ref P scenario would be useful, using transaction manager example.
<scribe> ACTION: David O will provide use case for Ref Props and Ref Parms by Dec 1.
<anish> ACTION: DaveO to come up with a usage scenario for refps by dec 1
Issue 9: Cardinality of properties and their values
Paul: if you have more than one thing, you have to describe how they are combined and how they are processed, In my proposal to close this issue, I stated we should not get too bogged down on how they are put together, but we should allow them.
... we should keep multiple endpoint references as being allowed
Chair: Have people had enough time to review this?
Chair: to clarify, the core will not disallow multiple references, but the bindings could add restrictions.
Paul: do not state how they are processed. The alternative is a placeholder uri for a processing style.
Chair: can you explain why to constrain in the bindings?
Paul: our bindings can be viewed as simplified
Chair: do you suggest we do not talk about cardinality in the core?
Jonathan: Are you proposing we say cardinality is 0 to N in the core, then limit it in the binding. Does this break down to multile reply to in the message, vs just an abstract model.
... we do state the processsing for 0 or 1 in the core. If we leave that soley to binding, we are left with a core which is not properly specified.
... to allow multiple reply to we would have to state how they are used. Why cannot this wait to a Version 2 spec, if we only use 0 or 1 now.
Marc: are we talking about multiple reply to vs making reply to contain multipe eprs.
Paul: these are separate issues. I would like to keep this focused on multiple reply to in the message.
Rebecca: It sounds like you are trying to get issue 26 out of existence.
Rebecca; by simplfying you are rejecting a set of use cases. The discussion needs to focus on whether these use cases are required to be supported.
Paul: what does multiple reply to mean to the receiver. We could annoint some uses but preclude others.
Chair: some of this can be moved to discusion of issue 26.
Anish: I do not understand why we could not constrain this at the wsdl mapping rather than the soap mapping.
... if we allow multiple reply to but restrict it as some level, the wsdl binding is a place to do this.
DaveO: the people that do not want to do it now are asserting it can be layere on, while others have stated that the way to do this is unknown.
Anish: I view this is different than issue 26. Issue 26 is to allow multiple ports to get to the same thing. This is different than multiple EPRs., which is the subject under discussion now.
Chair: either constrain in core spec, or constrain in other places.
Paul: I would like to think further on this, before putting together a proposal.
Chair: can you do this by Dec 1.
Paul: Surely
<anish> ACTION 3=paul to make a revised proposal for issue 9 by dec 1
<anish> issue 23: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0460.html
Issue 23: Anish posted a proposal.
Required properties in EPR: - Anish summarized his email.
Note: action on Paul is for issue 9 not issue 28
Anish: I would like EPR to contain all the information required, I would prefer to make contents required.
Chair: do you want all instances of EPRs to be dereferenceable?
Anish: Yes. Also I would like to see the addess we a full URI. An EPR out of context is not anything.
Dave: are you saying the structures of the EPR should be structured so all components of EPR are required, no matter what the context may be.
... do you want things that are often required to be always present?
Anish: yes
Dave: how far down the path do you go on this philosophy. The problem of making the qname required, is that when it is not needed it is irrelevant, and when it is needed, other things might be usefule as well. Taking this to the limit, would have any potential metadata included by ref or value in epr.
Anish: if service qname is there, but wsdl:location is not, the consumer can make a decision is cannot use epr, just because it does not have the wsdl.
... given we are talking about communicating with web services, the service qname should be required.
Dave: are you suggesting that adding the service qname enables enough systems to get the proper information required, warrants its use.
Anish: If we do not make it mandatory, it becomes a "logical address". If you need multiple protocol ports, the service qname will let this be known.
Gudge: I replied to the initial mail, but so far there has been nothing back. What do you mean by dereference an epr.
<GlenD> +1 - no need to make all EPRs contain everything all the time
Gudge: by design there are cases where EPRs are scoped to a context, where there is no such need. Port type is known by some other way by the participants.
... the EPR works in this context, but not in a wider context.
<GlenD> This is why we wanted the ability to annotate schema with WSDL metadata, for instance - so you could just pass something like a URL and "know" what kind of service/binding/etc that URL points to
Gudge: requiring wsdl port type and service name is not always appropriate.
Tom R: There are cases when a design may want to pass EPRs for extensibility, but the system can be configred in a tight context, as an optimization, to not required unneeded parameters in a specific context of use.
Anish: I want to avoid deficieint E
Deficient EPRS, to help interoperability.
Rebecca: How does this relate to Issue 33 on wsdl information in EPR? There are times that port types are known. What does this have to do with requirements on EPR options, outside of issue 33.
Anish: I thought 33 was optionally allowing a ref to where the wsdl is, or including the entire wsdl def in the EPR itself.
Rebecca: We suggested a reference to the WSDL.
Anish: issue 33 proposes an optional url which refers to the WSDL. This is slightly different, but related.
<Zakim> Marsh, you wanted to ask whether wsdlLocation is part of the context
Jonathan: where do you draw the line. I should be able to yank the EPR out of its context and use it. What else do you need to know outside the service name and the interface? To satsify the goal of all EPRs being context independent, this leads to puting everything into the EPR.
Anish: the user may decide that an epr does not have enough information for it to be useable.
... service qname captures different ports, the port type, bindings, features, properties, and schema. It answers where, what and how questions.
Gudge: The difference in Rebecca and Anish positions are regarding where to place the 80/20 line.
DaveO: I find it compelling that the html spec does not require html Base if any of the url's included are relative. If you get this relative URL, and the provider has not provided the context, that is too bad, and if you cannot interpret the relative urIi it will fail.
Anish: if there is no base specified, is the server considered to be the base?
DaveO: there is an algorithm, but the html spec does not state that one of these outer contexts must provide the base. the URI spec just states the order to do stuff. The sender choses what they want to provide for these contexts.
Chair: does Anish want service name and port type to be included.
Anish: perhaps port type is not needed if you have service name.
Chair: are there any other options to consider?
Jonathan: leave the interface and service qname optional, but add guidance that use of the EPR outside a specifric context would benefit by adding this information.
Anish: leaving it optional is not appealing to me, architecturaly.
... I would like to get a sense on the acceptability of my proposal, before writing it in detail.
<Marsh> + stausquo
Chair: Straw poll: a) status quo, a) Anish Direction, Not enough Information.
Tom Rutt wants status quo
Anish - required.
Marc: need more discussion
Many expressed status quo.
Marc: In general I am against making any of these things mandatory, for there are some uses where they are not needed.
15 for status quo
1 required
1 not sure
<pauld> + where the heck he
Anish: I think it might be a waste of my time to provide use cases, given this poll.
Rebecca: since there is overlap with issue 33, it would be worthwile to work out both together.
Marc: you could have multiple services in a wsdl, so that does not help much.
Anish: My issue is changing optionality of service qname to mandatory, this is different than issue 33.
Chair: some people want to continue discussion, does Anish want to make a proposal.a
anish: do you want exact wording?
Chair: outline the proposed changes, however I do not know how it will change the results.
Jonathan: a more concrete use case would be required to change my mind.
Anish: people are saying that there are use cases where this does not have to be mandatory.
DaveO: three use case: 1) service qname not needed, 2) exaclty what is needed, 3)is not suffiicient in itself
<scribe> ACTION: Anish to provide more justification.
Anish: what is so costly about always sending service qname.
Gudge: It might not always be available.
<anish> ACTION: anish to provide more usecases/justification for issue i023 by nov 24
Chair: lets move to Issue 28: semantics of reply to.
Chair: there may be some other issues embedded in the discussion of this issue. I would like to get a sense on this.
Marc: what this flushed out is a scoping question on some of these headers. I was assuming the scope is for MEP, while others are giving it a wider context. EG. Martin stated that the replyTo may not be used for on MEP but would be used for a follow on MEP. I would really like to get this understanding down.
Paco: the history of the spec is not scoped to a single MEP. I believe replyTo is for a wider context.
Marc: the semantics of reply to depend on the answer to this question. I
<scribe> ACTION: Marc H will raise a new issue about the "MEP" scope of the parameters.
<anish> ACTION: Marc H will raise a new issue about the "MEP" scope of the parameters.
Chair: that is all we have today.