WS Policy WG January 2007 F2F, day 2
17 Jan 2007


See also: IRC log


cferris, tboubez, trutt, FrederickHirsch, asir, danroth, Nadalin, umit, Ashok, maryann, PaulC, dorchard, whenry, prasad, fsasaki, Fabian, charlton, Symon, Charlton, Abbie, Yakov
Felix, Prasad


meeting start

chris: long agenda today
... paul suggested yesterday that today we focus on WSDL element id first
... after that we do what Fabian asked for , after that LC issues
... after that primer issues. That's rough schedule for today, comments?

Paul: one suggestion:

Paul: I have to leave at three o clock today, I'd like to talk about CR before, could we do that for lunch?

Chris: sure
... after lunch 30-45 minutes

Paul: Chris will chair the rest of today and tomorrow

WSDL 1.1 Element Identifiers

<Ashok> pl post link to document on IRC


Paul: the document is now a "editors team" document
... but still David's name should remain first on the publication
... great thanks to Dave for his work on the document!

chris: Dave, is this the right version?

Dave: yes

Paul: all AIs related to element identifiers (agenda item 1)) done
... only need bug numer for AI-188

(Chris goes through the AIs related to element identifiers)

Chris: we start with 4127, Fabian's issue

Fabian: WSDL 1.1. allows several operations with the same name on the endpoint
... original proposal does not take that into account
... dave has listed the 5 options to resolve the issue

<cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4127

Chris: above is the issue, Dave added that information to the issue

Dave describes http://www.w3.org/Bugs/Public/show_bug.cgi?id=4127#c1

Chris: who is fine with no 1?

10 people

Chris: who is fine with no 2?

5 people

Chris: who is fine with no 3?

9 people

Chris: who is fine with no 4?

Prasad: question on no 4: does WSDL 1.1 require input names to be unique?

Chris: you mean the name of the element?

Dave: the value of the @name attribute at the element

Prasad: is that enough? Can you still have conflicts if the output is different? The combination of both, "input, output"
... I thought the combination needs to be unique

Dave: do you have an example?

Prasad: Not 100% sure, looking it up

Chris: who is fine with no 4?

5 people

Chris: who is fine with no 5?

5 people

Chris: "who can not life question":

Monica: Fabian cannot life with 2 and 3

<Ashok> I have a preference for 5

Chris: preferences?

Ashok: preference for 5

Chris: 4 have preference for 5

Dave: I prefer no. 3
... can life with 5, it covers a scenarios, but it's a bunch of work for little gain

Glen: Dave, how would the URI be for 3 and 5?
... how would the difference be?

Dave: the example is in the bugzilla entry

Chris: preference for 3?

3 people

<Yakov> +1 to 3

<prasad> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4127

Chris: let's knock out 2 and 4
... now only discuss 1, 3 and 5

<dorchard> <op name="foo"><input></op>

<dorchard> <op name="bar"><input/><output/></op>

<dorchard> <op name="foo"><input/><output/></op>

Dave: my example does not address Fabian's concerns, I think now
... 5 does not really address the problem

<prasad> That is the issue I was raising, <input> element alone is not enough to distinguish between two operations, with the "same name"

Chris: now about 3, who still cannot live with it?

Fabian: 3 would be a real problem if you use more than one operation with the same name

Dave: understand, if there is overloading, you could not specify the second or third choice

Glen: you need to specify them somehow, e.g. by cardinal ordering

Dave: if you do overloading: are they disambiguated by input / output children? Or also differentiate them by names?

Glen: operation overloading was tied to RPC load, wanted to be able to map a Java object to WSDL
... in document literal world, now you have different elements

Dave: so combination of input / output with name attribute is sufficient?

Glen: no, you need the name
... the disambiguation happens on the qname of the input element. The output does not really matter, you can't overload s.t. with the same arguments

chris: is this an academic exercise?
... i.e.: the name of the operation is just the name attribute on an element

Glen: the name got used in code mapping. If I have a Java object, that gets mapped to a WSDL in some cases

Chris: how many people do this?

<dorchard> So does adding the message attribute qname value disambiguate?

<dorchard> ie, wsdl11.portTypeOperation(TicketAgent/listFlights(tns:listFlightsRequest))

<prasad> Slightly old but addresses this aspect in depth: http://webservices.xml.com/pub/a/ws/2003/01/08/randyray.html

Glen: I do that

Chris: o.k., different question: Do you have a real-world use case for two different operations with the same name, where you look in the input message parameters to distinguish?

Glen: it's unlikely

Chris: so I come back to option 1 or 3

<dorchard> The other option is based upon the name of the input, ie wsdl11.portTypeOperation(TicketAgent/listFlights(foo))

<dorchard> when <input name="foo" message="tns:listFlightsRequest"/>

Chris: how about option 6 "the identifier resolves to all operations"?

Fabian: don't think it's perfect, but I could live with it
... looking for a solution that will not create real-world difficulties

Chris: new option 6 - who can live with it? 14 people

Symon: a comment: use case of a different policy. You need to define which part to sign by the namespace. Imagine there is a change of namespace.
... you might need to have a new policy, just because of the namespace change

Glen: that does not apply here

Chris: who cannot live with 6?

WG agreed on direction on resolution: 6. Dave will update Bugzilla so before lunch

Chris: O.K., next one is http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045

(scoping of WSDL element identifiers spec)

Chris: proposal is to be constraint to be consistent with attachment points defined in the attachment spec
... my mail on the issue, finishing AI 173


Paul: the document discusses element identifiers in general
... the WSDL WG let us go with it so far
... we should rename the document "WS Policy WSDL 1.1. element identifiers"
... in our spec, we should make explicit which identifiers are valid attachment points
... the WG said they wanted to have an informative reference to the document
... under Chris proposal, I'm not sure how we can do that
... we can't have a normative reference to a note
... in summary: I agree with Chris proposal
... my counter proposal is: don't use the word "policy" in the document
... if we delete many rows, the WSDL WG might say "you did not do what you promised"
... so we need to find in the attachment spec where the valid attachment points are
... Asir said: the non-normative reference can be high up
... so two decisions: do we agree with the sentiment to your proposal
... if we do that, we should structure that in the way so we can use it
... and we need to be able to reference that from the attachment spec
... the Key we have is the first column of the table in the element identiers draft
... we could say "the valid attachment points for WSDL 1.1. are the same as the elements which are listed "

Chris: so: anybody who would disagree with the general "theme" to say: the set of external attachment points are the same as the set of internal attachment points?

Felix: need to make sure WSDL WG agrees

Paul: not necessary, they would have given us a LC comment already

Felix: only necessary to get agreement if we want to have a normative document on WSDL 1.1. element identifiers

Paul: sure, but that's not the question here

Chris: we had the document out for LC, we had no comments on this question
... so everybody fine with constraining the element idenfifiers?

Prasad: How about 4127? Will we leave the element ident spec as it is?

Chris: yes

Dave: what you do in the WSDL 1.1 element ident spec: you say you don't disambiguate
... in the attachment spec you say: operations apply to all elements

Paul: agree, element identifiers is a generic sub routine

Tony: I don't agree with first sentence in sec. 4 of attachment spec

Paul: that will change, editors have an AI to change that, related to WSDL element ID spec

Asir: decided to add a reference to WSDL 1.1., it is an outstanding action waiting for element ID draft
... one thing: waiting for a concrete proposal

Chris: agree, now I'm looking only for a direction

Paul: so we have a consensus that we need a restricted scope.

<Ashok> Agree with PaulC

Paul: my recommendation is : we should leave the WSDL 1.1. document as a generic document, and make the restricted scope in the attachment spec
... Chris said "delete the rows we don't use", I say: we need new text in the attachment spec

Chris: so we don't change the scope of sec. 4 of attachment spec

<dorchard> previous issue proposal, to add at the end of 3.4.1.

Chris: and say: the element identfifiers which are scope of attachment need to be described in attachmetn spec

<dorchard> "When a URI domain expression does not uniquely identify resources (such as WSDL 1.1 operation name overloading), the Policy applies to all the resources that are identified."

Dave agrees to flesh out a proposal for attachment spec

Asir: I don't understand Tony's comment on first sentence of sec. 4 in attachment spec

Maryann explains Tony's comment

<scribe> ACTION: David to make a formal proposal for WSDL 1.1. element identifiers referenced by / within attachment spec [recorded in http://www.w3.org/2007/01/17-ws-policy-minutes.html#action01]

<trackbot> Created ACTION-197 - Make a formal proposal for WSDL 1.1. element identifiers referenced by / within attachment spec [on David Orchard - due 2007-01-24].

Chris: now issue 4208, see http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0094.html

Dave: we should use element names "input" and "output", change "In" and "Out" for message references

Chris: for this issue there are two proposals: Dave and Ashok
... Ashok's proposal has no issue number, but is related

Dave: we could say: "let's do this". Ashok could say: "I don't like 'input' and 'output' at the end"

<dorchard> I think we should adopt mine, and then look at Ashok's.

Chris: sounds reasonable

Ashok: like the word in the message name rather than the qualifiers at the end

Chris: an example?

Umit: both for Dave and Ashok?

<dorchard> wsdl11.portTypeMessageReference(TicketAgent/listFlights/input)

<dorchard> Ashok's pref: wsdl11.portTypeinput(TicketAgent/listFlights)

Ashok: that's my proposal, the word "input" or "output" in the "method" name

Chris: WSDL WG said: "In" and "Out" are inappropriate
... can we assure it is input and output for both and close 4208?

Ashok: fine by me

Chris: everybody fine with that?

<prasad> Should it be wsdl11.portType.input(TicketAgent/listFlights) and wsdl11.portType.output(TicketAgent/listFlights)?

<prasad> I.e. not munge like "portTypeinput"

RESOLUTION: 4208 is resolved by http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0094.html

<prasad> I hope that was a typo

<umit> +1, that is my point as well.

<dorchard> My guess is that there should 3 options:

Chris: Ashok, could you open an issue about your mail?

<dorchard> 1) as-is

Ashok: let's discuss this briefly

<dorchard> 2) wsdl11.portTypeinput(TicketAgent/listFlights)

<dorchard> 3) wsdl11.portType.input(TicketAgent/listFlights)

<not-cferris> here is the note to the thread to which Ashok is referring: http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0092.html

Paul: we are not sure about the answer of WSDL WG on that

<prasad> What is the argument for option (2) over (3)?

Dave: we need to align the people as closely as possible
... we are not far enough to judge if it matters

Chris: I think it's just syntax

Umit: don't think it's just syntax

<umit> there are two languages, WSDL + Messages

Chris: question again to Ashok: could you raise an issue on WSDL element identifiers, with a link to mail thread from Jonathan
... that would be the remaining open issue

<umit> option 3 is clearer on the boundary.

Chris: question: if we resolve this issue, could we publish the WSDL 1..1 spec?

Ashok: yes

<prasad> +1 to option 3

<scribe> ACTION: Ashok to open issue on WSDL 1.1. spec with a link to mail thread from Jonathan [recorded in http://www.w3.org/2007/01/17-ws-policy-minutes.html#action02]

<trackbot> Created ACTION-198 - Open issue on WSDL 1.1. spec with a link to mail thread from Jonathan [on Ashok Malhotra - due 2007-01-24].

Paul: Ashok, when you open the mail thread, the bug will identify the three alternatives in IRC?

1) as-is , 2) wsdl11.portTypeinput(TicketAgent/listFlights) , 3) wsdl11portTypeinput(TicketAgent/listFlights)

Chris: WSDL WG said they don't have an opinion on this

<umit> 3 is wsdl11.portType.input(TicketAgent/listFlights)

<umit> the "." is significant

<umit> the "." is significant

thanks, Umit

<prasad> Say it again?

Chris: preference for 1)?

2 people. Chris: preference for 3) (2 is dropped)?

4 people

Chris: who needs time?

5 people

<Yakov> +1 for more time

Paul: who does not care?

3 people

Chris: who cannot live with 1)?

4 people

Paul: please look at wsdl11.portType.input(TicketAgent/listFlights) and check if it works

Ashok: I'll do my AI on this within an hour

Chris: now break, after that v.next
... coming back at 10:55

<Fabian> pong

v.next issues

Fabian: on http://www.w3.org/Bugs/Public/show_bug.cgi?id=4178

Chris: everybody understands the issue?

(no questions)

Chris: everybody fine with closing this as v.next now?

Prasad: what does marking as "v.next" mean now?

<dorchard> Proposal for scoping of wsdl, bug 4045, updated at http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045

Chris: at Proposed Rec stage, we look at them

Paul: keyword is "futureConsideration"

<asir> use the following URI

<asir> http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&order=relevance+desc&product=WS-Policy&content=&keywords=futureConsideration

<prasad> Keywords URI: http://www.w3.org/Bugs/Public/describekeywords.cgi

Paul: so we close the issues as "won't fixed" and use the keyword "futureConsideration"

Chris: so everybody fine to close 4045 with "won't fixed" and "futureConsideration"?

RESOLUTION: everybody fine to close 4178 with "won't fix" and "futureConsideration"

Tony: can we make new proposals later?

Paul: yes, this is a candidate list

(fix 4045>4178 in the minutes later)

Chris: now 4179

Fabian on http://www.w3.org/Bugs/Public/show_bug.cgi?id=4179

Chris: discussion? Objections to close this like 4178?

RESOLUTION: everybody fine to close 4179 with "won't fixed" and "futureConsideration"

<not-cferris> ping

Last Call Issues Part I

Chris: now 4206

<not-cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0172.html

(Fabian explains the mail)

Chris: so proposal is to add sec. 3.2

Monica: right, and to make explanation in sec. 4.5

Frederick: is this the issue "you don't know howt to intersect if you have parameters"?

Monica: yes

Frederick: important and good issue

Fabian: look at sec. 4.5
... the end of the example , there is an explanation , in the context of the example

Chris: proposal in the original bugzilla entry should be replaced?

Monica: we could separate the other parts of the original proposal, to allow to close the LC issue

Chris: new proposal replaces the original proposal by replacing one sentence in sec. 4.5 , to refer to sec. 3.2
... that would be enough to close 4206
... and we could work on the other aspects of 4206 later

Monica: yes, we just need an AI for these aspects

Frederick: does that really resolve the issue?

Umit: the point was to have a default

Frederick: the issue was: what to do if there is a conflict, what are the options?
... why don't we describe the options

Asir: they took the security token as an example

Frederick: there was a class of issues

Asir: not aware of *class* of issues, just security token

Frederick: can't describe the class now, but have the feeling there was something

Fabian: original proposal was to suggest as a default to check all assertion parameters for compatability or exact matches
... we realized in the meantime that this is s.t. you can't do with an XML infoset
... to establish equality of two XML infosets
... the framework suggests only QName top level matching. We think now that this is the right thing to do

Chris: again: revised proposal is instead of changing the algorithm is to add the reference to sec. 3.2

Fabian: in XML there is no reliable way of canonicalizing two XML infoset

Frederick: so a domain could have one more than one representation for a value

Asir: yes, e.g. different order of values

Frederick: what is the error condition?

Asir: there is none, it is an undefined behavior

Umit: QName is fine. But if you have parameters and there is no idea about domian specific processing
... you could default to fail

Chris: no, the framework will say "if the QNames are the same, they are compatible", there is no failure

Dan: parameters are the payload of the assertion, they are not relevant for compatability

Chris: so latest proposal is to add the reference to sec. 3.2 and to have an AI against primer and guidlines for other changes
... proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0172.html
... fine with closing the issue with that resolution?

RESOLUTION: 4206 closed with proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0172.html

Chris: next issue is 4196

<not-cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0083.html

Chris: schedule changed, now 4198

<monica> For 4198: updated http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1

Fabian describes 4198

Chris reads proposal at http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1

Chris: sounds good to me, fine to close 4198 with that?

Tony: WS-PolicyAttachment defines only certain mechanisms, there could be others
... should be clarified that this is particular to the mechanisms that WS-PolicyAttachment defines
... so is this be scoped to what is definded in WS-PolicyAttachment?

Fabian: why should this be restriced?

Tony: other domains may not want to buy this

Fabian: it's guidelines, so no normative text

Chris: essence of the point is: assertion "foo" means "foo", no matter what attachment I use

Tony: unless it has parameters :)

Dan: you should not tie semantics into the attachment mechanism

Tony: don't agree, In security policy, we say what valid subjects you can attach the policy to

Dan: agree with what you say, but the *way* you attach the subject, e.g. external versus inline, does not matter
... no matter what mechanism you use, the semantics should be the same

(Chris types a proposal)

<not-cferris> Although a policy assertion may be tailored for or constrained to a specific set of

<not-cferris> take 2

<not-cferris> Although a policy assertion may be tailored for or constrained to a specific set of policy subjects by design, its semantics are not dependent upon the mechanism by which a policy expression is attached to a given policy subject. For instance, an assertion "Foo" has the same semantic when attached to a WSDL1.1 operation regardless of whether it was attached using XML element policy attachment or the external URI attachment mechanism.

<not-cferris> Dan suggests s/are not/should not/

Chris: better "should not be"

Tony: what brought up the issue?

Umit: we have now various ways of attachment
... the problem is to have a "sub routine" to make sure that the semantics are the same

Tony: I could have an assertion attached to WSDL, I could do the same for a message
... how do you determine the subject?

Maryann: we don't have examples for that

Umit: given a domain, people should not have a fixed set of policy subjects?

Tony: it may not be the case, the assertion may be dynamic

Fabian: don't think it's an issue here
... only question is if I should recommend which mechanism to use, or leave it up to the implementers?

Umit: the statements says "a policy assertion may be tailored for a specific set of policy subjects by design"

Dan: attachement spec says: the operations you are supposed to do (merging) are also independent of the attachment mechanism

Tony: willing to go along with that change, but needs to be looked at in v.next

Chris: other discussion?

RESOLUTION: http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198 closed with proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1 as amanded by Chris here: "Although a policy assertion may be tailored for or constrained to a specific set of policy subjects by design, its semantics are not dependent upon the mechanism by which a policy expression is attached to a given policy subject. For instance, an assertion "Foo" has the same semantic when attached to a WSDL1.1 operation regardless of whether it was attached using XML element policy attachment or the external URI attachment mechanism."

break now, resume at 1 p.m. pacific time

after lunch, discussion on getting out of LC > going into CR

<scribe> scribe: prasad

<not-cferris> we're starting up again

Candidate Recommendation schedule and exit criteria


Paul: No detail on the agenda item
... it is important that we all have same understanding
... we need directors approval to go from LC to CR

Paul walks through the document at http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0175.html

a draft schedule

Goal to make March f2f interop testing meeting

a) W3C process

Substantive changes like adding ignorable in LC would require another LC

Not in our case

paul walks through (a) 1-7

scribe: clarifies consensus and formal / minority objection

walk throgh of item (b)

If we close all LC issus this week, we can get ready for directors call with chairs in Feb sometime

Paul; It is not required to show that a technical report has two independent and interoperable implementations

scribe: as part of the director's request. However, the WG should include a report of present and expected implementations as part of the request

After gathering implementation experience, the WG may declare certain features as being "at risk"

scribe: AC reps may appeal the decision to advance

Paul: That is the summary of how to get out of LC and what to do in LC

Felix: It is not 100% necessary that the chairs attend the call with the director. The Director may rely on W3C's rep's recommendation

Paul: Item (c)
... Sometime back IBM and MS submitted scenarios doc


Asir: Explains color coding in the scenarios doc

Paul: As soon as we exit last call we will start getting volunteers to work on available scenarios in the document
... W3C does not limit two two participants in the WG anymore
... the chairs welcome WG companies bringing new resources
... If we don't get volunteers, we will schedule time on regular calls to work on the scenarios

(e) Draft schedule

Umit: Are you going to publish what IBM and MS are working on?

Paul / Chris: Yes, see the next items in (e)

(1) IBM and MS contribute the updated scenarios pack

may be end of next week..?

say Jan 26th

(e-2) Close Last Call issues .. Jan 18

(e-3) Co-chairs establish a plan to complete the remaining scenarios work Jan 26

(e-4) Editors deliver CR drafts for publication - Jan 26

(e-5) WG members review of candidate CR drafts Jan 31

(e-6) hairs prepare disposition of comments and other LC evidence - Jan 31

(e-7) Co-chairs' CR conference call with the Director and other W3C staff - 2nd/3rd wk of Feb

(e-8) Editors deliver Scenarios for publication - Prior to call with the Director

(e-9) Remaining scenarios are due - TBD

(e-10) Director's decision and CFI announcement -- 3rd week of Feb

(e-11) CR publication, WG publishes the First Public Working Draft of Scenarios - 3rd week of Feb

(e-12) Editors deliver updated Scenarios for publication - TBD

(e-13) WG publishes the Second Public Working Draft of Scenarios -- TBD

(e-14) Mar 13-15 - WG F2F meeting in SFO, co-chairs invite implementers to attend

(e-15) 2nd Interop scenarios added in 2nd WD scenarios -- TBD

Asir: Publish scenarios in Word?

Paul: I am happy with PDF

Felix: Where do the scenarios docs get published? In WS-Policy WG space or W3C public Rec space?

Paul: We should put it on WG page not the TR page

WSDL 1.1 Element Identifiers and Last Call Issues continued

Chris: Issue 4045


Paul: Explains David's proposal for 4045 and 4127 combined with Editors AI 112

<asir> +1 to Dave's proposal

<scribe> ... New text: When a URI domain expression identifies multiple resources, ie WSDL 1.1 supports multiple operations with the same name (sometimes called operation name overloading), the Policy applies to all the resources that are identified.

IRI References for WSDL 2.0 components are defined in Appendix C of the Web

scribe: IRI References for WSDL 1.1 elements are defined in WSDL 1.1 Element Identifiers [ref]. The scope of URI domain expressions for WSDL 2.0 components or WSDL 1.1 elements is limited to the subjects defined in this specification at (ref to Attaching Policies Using WSDL 1.1 and WS-Policy Attachment for WSDL 2.0).

The above change as now shown in the 4045 bug updated text, goes in 3.4.1:

Chris: Comments, Qs? Discussion?
... any objections to closing 4045 and 4127?

Monica: Allow fabian to comment?

Paul: He said he won't be here tomorrow morning and this is the sentiment we agreed to this morning

Chris: Tony, what to do with 1st sentence in section 4 Attaching Policies in WSDL 1.1 of the WSDL element identifiers doc?

Asir; What is chris' concern?

Chris: The paragraphs in section 4 do not talk about external attachment

Paul: section 5 for WSDL 2.0 does not say anything about preferences. Should we similar thing for WSDL 11 and get rid of recommended completely

Maryann: Not sure how it fits with calculating effective policy

Chris: What if there is one inline and also attached

Dan: Effective policy applies to both. does not matter where you get it from

Maryann: I need to read through that section but, ok

Asir: This recommendation is only in section 4

applies to that section only

Maryann: Then you have two references to doing things with WSDL 1.1, section 3.5 and this one

Paul: I have an updated proposal to address this
... discussion and attempts to refines paul's proposed changes to section 4 1st few paragraps of Attachment spec

Asir: suggests copying the corresponding text for WSDL 2.0 and replacing component with construct and WSLL2.0 with WSDL 11 etc.

Maryann: we need symmetry in the section title also
... further wordsmithing..

<scribe> New proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045

This is to resolve 4045 and 4127 and Editors AI 112

Review the text during break


Reconvene in 15 mins

at.. 2:45pm

<not-cferris> we are about to resume

Chairs: Opening the floor for the discussion of the proposal

Asir: I need more time

Chris: I would rather not context switch again..

Asir: ready to go
... we can go as proposed. No changes to the proposal

Chris: Are we good to go for this as combined proposal to close 4045 & 4127

<not-cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c2

<not-cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c3

RESOLUTION: Close 4045 and 4127 with text as provided in http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c2 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c3 respectively

Chris: Issue 4196


proposed change for Framework, Section 2.2:

Extensions that are Child Element Information Items added to Policy operators wsp:Policy, wsp:All and wsp:ExactlyOne MUST NOT use the policy language XML namespace name

Daveo: See section 2.1 in FWK doc

The ellipses characters are used to indicate a point of extensibility that allows other Element or Attribute Information Items .. etc.

scribe: we have 2 different ways of talking of extensibility; short hand ... form
... and specific ones with {any} and @{any}

in each of the sections applicable

We have general model in section 2.1 and 2.2 and specific ones in the actual sections of the spec

Daveo: so, it does not make sense to add this change to section 2.2
... it is in the guidelines doc we should say "don't put extensions in policy namespace"

So, none of this belongs in the FWK doc

<PaulC> Paul is leaving the F2F now.

<PaulC> I hope to join by phone for parts of tomorrow (Thu).

scribe: discussion on daves asserition that this does not belong here ..

Chris: The text "If an Element Information Item is not recognized, it MUST be treated as a policy assertion ..." is problematic
... if they are recognized, what to do? it does not say

Glen: We don't have something like SOAP processing model for policy

Monica: regardsless of where we place the text, noone said, what we proposed is not what we want

<umit> +1 to Monica

Daveo: Not to use ws-policy namespace for extensions is implied by the references we have

Umit: It is implicit not stated explicitly

Daveo: The spec covers it. We don't repeat things

maryann/umit: where does the spec state it?

Daveo: section 2.3 -- "All information items defined by this specification are identified by the XML namespace URI http://www.w3.org/@@@@/@@/ws-policy"

Chris: We have an open issue 4238 - we don't have normative description of compact form except in schema

<dorchard> In a "compact form" section, you'd have something like /Policy/{any} - allows elements from other namespace

dan/asir: sounds great

<asir> 4238

Chris: keep 4196 pending
... Issue 4238
... Section 2.1 says "Normative text within this specification takes precedence over normative outlines, which in turn take precedence over the XML Schema [XML Schema Structures] descriptions." But outline for compact form points to normative form. Which means compact form is not allowed

Asir: The best way to move forward is for someone to make a formal proposal. I can take thye action if we set the criteria
... one criteria - outline for compact form should be in sync with schema
... another criteria, address Monica's concern

<dorchard> http://www.w3.org/TR/2006/CR-wsdl20-20060327/#language-extensibility

<not-cferris> wsp:Policy/{any} (line break) an extensibility point that allows inclusion of elements. Such elements MUST NOT have the policy language XML namespace name.

<not-cferris> this should be taken as input requirements to the proposal for closing 4238 and 4196

<scribe> ACTION: Asir to make a proposal based on the guidelines to close issues 4238 and 4196 - due by tomorrow morning [recorded in http://www.w3.org/2007/01/17-ws-policy-minutes.html#action03]

<trackbot> Created ACTION-199 - make a proposal based on the guidelines above or criteria above to close issues 4238 and 4196 [on Asir Vedamuthu - due 2007-01-17].

Issue 4138

see: http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0166.html

Asir: Explains the proposal - joint from Asir, Umit and Dan

Chris: Comments? Concerns?
... Objection to closing 4138 with the above?

<not-cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0166.html

RESOLUTION: 4138 closed with proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0166.html

Now issue 4240


Spec says: Distributing wsp:All over an empty wsp:ExactlyOne is equivalent to no alternatives.

Discussion between Dan and Umit how to explain this with other rules, viz. distribution etc.

Asir's resonse to issue: http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html

<not-cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html

<not-cferris> Distributing wsp:All over an empty wsp:ExactlyOne is equivalent to no alternatives. *** reslution in msg 173 goes here *** For example,

In section 4.3.3 put the base case described in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html prior to current example identifiedin the issue

RESOLUTION: Close issue 4240 with "In section 4.3.3 put the base case described in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html prior to current example identified in the issue"

Now issue 4235

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0159.html

Chris: Describes the issue and proposed resolution

Glen: Did we check what the policy attachment spec says?
... I beleive the intent of the attachment spec is spelled out. We don't need anything more

<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0159.html

RESOLUTION: Close issue 4235 with proposal outlined in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0159.html

Chris: Reviews open LC issues at this point

<fsasaki> http://lists.w3.org/Archives/Member/chairs/2006JulSep/0113.html

<fsasaki> http://www.w3.org/2005/07/13-nsuri

4196 and 4238 pending proposal from Asir

Issue 4251 discussed already

Now issue 4254


<fsasaki> http://www.w3.org/ns/ws-policy

<fsasaki> (will be the new policy ns)

RESOLUTION: close issue 4254 with adoption of the new namespace http://www.w3.org/ns/ws-policy

Primer Issues

Issue: 4041

Asir: likes to defer to tomorrow

Issue: 4103 Questionable use of Contoso


<umit> +1 to company A

Chris: describes the current status on the discussion and research on this, by Felix and others
... Company A seems non-controversial

Asir: Company A is a registered trademark

Frederick: How about Felix's suggestion of "Example company .."

Prasad: How about Fake-Company-A?

<fsasaki> example from web arch:

<fsasaki> "Dirk would like to add a link from his Web site to the Oaxaca weather site. He uses the URI http://weather.example.com/oaxaca"

Chris: Change the domain name in examples as subdomain of example.com
... Instead of using a named company, replace with a generic, "the company"?

Asir: If we say "A company", we will lose context when we talk about it in the examples

<umit> Here is some kind of text we use;

<umit> Let us look at a fictitious scenario used in this document to illustrate the features of the policy language. A Web service developer is building a client application that retrieves real time stock quote information from Contoso, Ltd. Contoso supplies real time data using Web services. The developer has Contoso’s advertised WSDL description of these Web services. Contoso requires the use of addressing headers for messaging. Just the WSDL description is not s

<umit> The SOAP message in the example above includes security timestamps that express creation and expiration times of this message. Contoso requires the use of security timestamps and transport-level security - such as HTTPS – for protecting messages. (The prefixes wss and wsu are used here to denote the Web Services Security and Utility namespaces.)

<umit> Similar to the use of addressing, Contoso indicates the use of transport-level security using a policy expression. The example below illustrates a policy expression that requires the use of addressing and transport-level security for securing messages.

Asir: If we say "A company", we will lose context when we talk about it in the examples

Moving on..

Issues: 4212, 4213


Maryann has action 192 related to this already

Chris: We are done with the agenda for today. We have AIs for pending LC issues

Check on peoples' availability / early departures tomorrow

Tony and William plan to leave early

Asir: Owners for remaining scenarios?

Chris: We can assign tomorrow
... Tomorrow's agenda - Going until 3pm. Remaining LC issue, Primer and Guidelines issues and Interop scenarios

Editors meeting at 3pm in this room

Claps for the progress made on the LC issues. Congrats to WG from Felix

<cferris> recessed

Summary of Action Items

[NEW] ACTION: Ashok to open issue on WSDL 1.1. spec with a link to mail thread from Jonathan [recorded in http://www.w3.org/2007/01/17-ws-policy-minutes.html#action02]
[NEW] ACTION: Asir to make a proposal based on the guidelines to close issues 4238 and 4196 - due by tomorrow morning [recorded in http://www.w3.org/2007/01/17-ws-policy-minutes.html#action03]
[NEW] ACTION: David to make a formal proposal for WSDL 1.1. element identifiers referenced by / within attachment spec [recorded in http://www.w3.org/2007/01/17-ws-policy-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/01/31 17:06:11 $