See also: IRC log
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
<Ashok> pl post link to document on IRC
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> 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
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 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
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
<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
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
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 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
Chris: Issue 4045
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 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> 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
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 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
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: 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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=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
Issue: 4041
Asir: likes to defer to tomorrow
Issue: 4103 Questionable use of Contoso
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 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
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