- From: Sergey Beryozkin <sergey.beryozkin@iona.com>
- Date: Fri, 19 Jan 2007 15:09:11 -0000
- To: <fsasaki@w3.org>, <public-ws-policy@w3.org>
Hi
A comment on one of the statements in the minutes...
"ignorable assertions always break strict mode clients"
Would it make sense to say the above is true only if strict mode clients do not find some expected assertion ? If they expect a
certain
producer's assertion then if this assertion is indeed available then it doesn't matter that this assertion might've been marked as
'ignorable'
Cheers, Sergey
> ----- Original Message -----
> From: "Felix Sasaki" <fsasaki@w3.org>
> To: <member-ws-policy@w3.org>
> Sent: Thursday, January 18, 2007 5:11 AM
> Subject: [WS Policy Working Group Jan 2007 f2f day 2 2007-01-17] minutes (DRAFT)
>
>
>
> ... are at http://www.w3.org/2007/01/17-ws-policy-minutes.html and below
> as text.
>
>
> Felix
>
>
> [1]W3C
>
> [1] http://www.w3.org/
>
> - DRAFT -
>
> WS Policy WG January 2007 F2F, day 2
> 17 Jan 2007
>
> [2]Agenda
>
> [2]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0161.html
>
> See also: [3]IRC log
>
> [3] http://www.w3.org/2007/01/17-ws-policy-irc
>
> Attendees
>
> Present
> cferris, tboubez, trutt, FrederickHirsch, asir, danroth,
> Nadalin, umit, Ashok, maryann, PaulC, dorchard, whenry,
> prasad, fsasaki, Fabian, charlton, Symon, Charlton, Abbie,
> Yakov
>
> Regrets
> Chair
> Chris
>
> Scribe
> Felix, Prasad
>
> Contents
>
> * [4]Topics
> 1. [5]Meeting start
> 2. [6]WSDL 1.1 Element Identifiers
> 3. [7]v.next issues
> 4. [8]Last Call Issues Part I
> 5. [9]Candidate Recommendation schedule and exit criteria
> 6. [10]WSDL 1.1 Element Identifiers and Last Call Issues
> continued
> 7. [11]Primer Issues
> * [12]Summary of Action Items
> _________________________________________________________
>
> 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
>
> [13]http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11element
> identifiers.html
>
> [13]
> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html
>
> 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> [14]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4127
>
> [14] 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
> [15]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4127#c1
>
> [15] 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> [16]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4127
>
> [16] 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:listFlightsRequ
> est))
>
> <prasad> Slightly old but addresses this aspect in depth:
> [17]http://webservices.xml.com/pub/a/ws/2003/01/08/randyray.html
>
> [17] 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
> [18]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045
>
> [18] 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
>
> [19]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/016
> 2.html
>
> [19]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0162.html
>
> 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 [20]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
> [21]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/009
> 4.html
>
> [21]
> 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
> [22]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/009
> 4.html
>
> [22]
> 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:
> [23]http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/009
> 2.html
>
> [23]
> 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
> [24]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 [25]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4178
>
> [25] 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
> [26]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045
>
> [26] 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>
> [27]http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&
> order=relevance+desc&product=WS-Policy&content=&keywords=futureConsi
> deration
>
> [27]
> http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&order=relevance+desc&product=WS-Policy&content=&keywords=futureConsideration
>
> <prasad> Keywords URI:
> [28]http://www.w3.org/Bugs/Public/describekeywords.cgi
>
> [28] 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 [29]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4179
>
> [29] 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>
> [30]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 2.html
>
> [30]
> 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
> [31]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 2.html
> ... fine with closing the issue with that resolution?
>
> [31]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0172.html
>
> RESOLUTION: 4206 closed with proposal in
> [32]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 2.html
>
> [32]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0172.html
>
> Chris: next issue is 4196
>
> <not-cferris>
> [33]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/008
> 3.html
>
> [33]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0083.html
>
> Chris: schedule changed, now 4198
>
> <monica> For 4198: updated
> [34]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1
>
> [34] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1
>
> Fabian describes 4198
>
> Chris reads proposal at
> [35]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1
>
> [35] 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: [36]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198
> closed with proposal in
> [37]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."
>
> [36] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198
> [37] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198#c1
>
> 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
>
> [38]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 5.html
>
> [38]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0175.html
>
> 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
> [39]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 5.html
>
> [39]
> 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
>
> [40]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/att
> -0143/ws-policy-features-01-15-2006.pdf
>
> [40]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/att-0143/ws-policy-features-01-15-2006.pdf
>
> 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
>
> [41]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045
>
> [41] http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
> [42]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045
>
> [42] 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
>
> >>>>>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>
> [43]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c2
>
> [43] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c2
>
> <not-cferris>
> [44]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c3
>
> [44] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c3
>
> RESOLUTION: Close 4045 and 4127 with text as provided in
> [45]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c2 and
> [46]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c3
> respectively
>
> [45] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c2
> [46] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045#c3
>
> Chris: Issue 4196
>
> [47]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4196
>
> [47] http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
> [48]http://www.w3.org/@@@@/@@/ws-policy"
>
> [48] 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>
> [49]http://www.w3.org/TR/2006/CR-wsdl20-20060327/#language-extensibi
> lity
>
> [49]
> 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
> [50]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:
> [51]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/016
> 6.html
>
> [51]
> 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>
> [52]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/016
> 6.html
>
> [52]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0166.html
>
> RESOLUTION: 4138 closed with proposal in
> [53]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/016
> 6.html
>
> [53]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0166.html
>
> Now issue 4240
>
> [54]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4240
>
> [54] http://www.w3.org/Bugs/Public/show_bug.cgi?id=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:
> [55]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 3.html
>
> [55]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html
>
> <not-cferris>
> [56]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 3.html
>
> [56]
> 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
> [57]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 3.html prior to current example identifiedin the issue
>
> [57]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html
>
> RESOLUTION: Close issue 4240 with "In section 4.3.3 put the base
> case described in
> [58]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/017
> 3.html prior to current example identified in the issue"
>
> [58]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0173.html
>
> Now issue 4235
>
> <cferris>
> [59]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/015
> 9.html
>
> [59]
> 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>
> [60]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/015
> 9.html
>
> [60]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0159.html
>
> RESOLUTION: Close issue 4235 with proposal outlined in
> [61]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/015
> 9.html
>
> [61]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0159.html
>
> Chris: Reviews open LC issues at this point
>
> <fsasaki>
> [62]http://lists.w3.org/Archives/Member/chairs/2006JulSep/0113.html
>
> [62] http://lists.w3.org/Archives/Member/chairs/2006JulSep/0113.html
>
> <fsasaki> [63]http://www.w3.org/2005/07/13-nsuri
>
> [63] http://www.w3.org/2005/07/13-nsuri
>
> 4196 and 4238 pending proposal from Asir
>
> Issue 4251 discussed already
>
> Now issue 4254
>
> [64]http://www.w3.org/Bugs/Public/show_bug.cgi?id=4254
>
> [64] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4254
>
> <fsasaki> [65]http://www.w3.org/ns/ws-policy
>
> [65] http://www.w3.org/ns/ws-policy
>
> <fsasaki> (will be the new policy ns)
>
> RESOLUTION: close issue 4254 with adoption of the new namespace
> [66]http://www.w3.org/ns/ws-policy
>
> [66] http://www.w3.org/ns/ws-policy
>
> Primer Issues
>
> Issue: 4041
>
> Asir: likes to defer to tomorrow
>
> Issue: 4103 Questionable use of Contoso
>
> [67]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/016
> 3.html
>
> [67]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0163.html
>
> <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
> [68]http://weather.example.com/oaxaca"
>
> [68] 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
>
> [69]http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/010
> 0.html
>
> [69]
> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0100.html
>
> 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
> [70]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
> [71]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
> [72]http://www.w3.org/2007/01/17-ws-policy-minutes.html#action01]
>
> [End of minutes]
> _________________________________________________________
>
>
> Minutes formatted by David Booth's [73]scribe.perl version 1.127
> ([74]CVS log)
> $Date: 2007/01/18 05:09:21 $
>
> [73] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
> [74] http://dev.w3.org/cvsweb/2002/scribe/
>
Received on Friday, 19 January 2007 15:07:42 UTC