See also: IRC log
<abbie> coffee
<abbie> +abbie
<cferris> scribe: Fabian
<cferris> scribeNick: Fabian
roll call done
<cferris> http://www.w3.org/2007/07/11-ws-policy-minutes.html
Monica did not see minutes
nobody objects to adoption of minutes
Frederick: continued work on guidelines, updated references in PR drafts of framework and attachment, also guidelines
Paul asked Felix to update public page with pointers to PR docs
Paul: page is updated
action 300 done, has an agenda item
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0023.html
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0008.html
need to add issue 322 to agenda
Asir: was there an email elaborating on best practice?
Paul: thread start with email #8
... mark 322 as done
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0024.html
Paul: Maryann posted doc file, can Charlton create PDF?
Charlton: being done
Paul: 323 done
<paulc> ACTION-325 Maryann to revise proposal for 4663 based on feedback from
<paulc> is still not done.
additional actions: 329
<paulc> Open actions: http://www.w3.org/2005/06/tracker/wspolicy/actions/open
330 is done
Asir: 331 still open
<cferris> 329 is also done
Asir: done next week
Paul asks Asir to report when action is done
Paul: 332 is pending
Chris: target date Aug 20
Paul: new PR item, WSDL 1.1 element identifiers reference
Chris: all AIs recorded
<cferris> http://www.w3.org/TR/2007/WD-wsdl11elementidentifiers-20070330/
Paul: only editorial AIs open + Monica and Maryann's
<abbie> virtual dinner
<paulc> Dinner on Tue: The first dinner venue (17th) is a Cafe Bar Deli at Grafton Str [1][2].
<asir> Cafe Bar Deli is at http://www.cafebardeli.ie/grafton/index.php
Paul: probably v.next discussion tomorrow.
current charter has new charter as optional deliverable
... straw man proposal, follow order of agenda, get as many items as possible
done and possibly get done early
... coffee break at 10:30
<paulc> [New Issue] Issue 4762: Media type section update, Felix
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0014.html
Paul: media type was registered
... will investigate what can be done that link back references PR
<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0022.html
Paul: Asir suggested change in framework, drop
sentence as mentioned in message 22
... Chris to update issue with Asir's suggestion
... resolve issue and action item on Philippe
<cferris> RESOLUTION: issue 4762 closed with recognition that media type is already registered, with action on philippe (felix) to resolve the issue of the corrected link to REC when published
<cferris> ACTION: Philippe to check with IESG regarding link from media type registration [recorded in http://www.w3.org/2007/07/17-ws-policy-minutes.html#action01]
<trackbot> Created ACTION-333 - Check with IESG regarding link from media type registration [on Philippe Le Hegaret - due 2007-07-24].
Paul: next item WSDL 1.1 element identifiers
reference
... attachment has non-normative reference to WSDL 1.1 element id doc, which
was published as WD
... suggest to publish this as WG note
... change reference in attachment
... A WG note means we do not take it through CR, PR, TR. instead simply
archive as result of work. indicates we agree on document, not normative.
<cferris> RESOLUTION: WG agrees to publish WSDL11ElementIdentifiers as WG Note
<cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4858
<paulc> Issue 4858: Update reference to WSDL 1.1 EI in Attachments doc
<cferris> ACTION: Felix to publish WSDL11 EII spec as WG Note and inform editors of link for the PR draft updates [recorded in http://www.w3.org/2007/07/17-ws-policy-minutes.html#action02]
<trackbot> Created ACTION-334 - Publish WSDL11 EII spec as WG Note and inform editors of link for the PR draft updates [on Felix Sasaki - due 2007-07-24].
Paul: no additional PR issues
... AC until August 17 to file opinions whether we go to REC status, WG
should meet on Aug 22 and take in eventual comments, projected date for
publication is Sep 4
... Will ask members for testimonials on REC until Sep 4
Paul: Monica opened new PR issue yesterday
... issue on Guideline, not primer
... added issue to guideline issues
... issue 4376
Asir: date for WS-A metadata PR after July 20
Tom: namespace is not going to change
Paul: Chris suggested to take primer/guidelines through LC
Chris: close with no action, can open new issue if namespace changes
Asir: already agreed to make changes
Chris: might want to update reference itself
<cferris> RESOLUTION: issue 4376 closed with no further action
<asir> Editors' action is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/331
Paul: 15 minutes break
<cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4852
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0018.html
<cferris> RESOLUTION: issue 4852 closed with proposed edits adopted, editors to incorporate changes
<cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4853
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0017.html
Asir: first part references EPRs, which we do
not define
... ExactlyOne, All operators only form alternative in normalized form
... suggest to drop both
Frederick: If you can normalize, why isn't it equivalent logically
Asir: yes, but need normal form to make that statement
Chris: statements are correct
Asir: statement not relevant to section minimal approach
Chris: paragraph builds up step by step
<maryann> +1
Asir: drafts policy that does not fulfill
condition on drawing board
... policy alternative only has meaning in normal form
... we can talk about group
Monica: can we just delete last part of sentence?
Asir: fine with just deleting incriminating part
Chris: does not claim that it is a complete alternative
Paul: "they now constitute a policy alternative"
<fjh> issue is that strictly speaking policy alternative is only within a top level normalized policy, but informally we look at a nested policy and can view the contents as alernatives
<fjh> but this is not strictly correct
Paul: just remove "and they now constitute..."
<cferris> sIf grouping is utilized, choices between alternatives can be indicated by an
<cferris> "exactly one" operator./If such grouping is utilized, choices between such groupings can be indicated by an
<cferris> "exactly one" operator./
Asir: Chris suggestion is a correct statement
<paulc> Above change is Part 2.
<paulc> Part 1 is remove "and they now constitute a policy alternative. "
Paul: Asir and WG OK with part 1
<cferris> RESOLUTION: issue 4853 closed with above proposal
<cferris> 04[06:14] cferris: 01sIf grouping is utilized, choices between alternatives can be indicated by an
<cferris> "exactly one" operator./If such grouping is utilized, choices between such groupings can be indicated by an
<cferris> "exactly one" operator./
<cferris> 10[06:15] scribe: 01Asir: Chris suggestion is a correct statement
<cferris> 10[06:15] paulc: 01Above change is Part 2.
<cferris> 10[06:15] paulc: 01Part 1 is remove "and they now constitute a policy alternative. "
<paulc> part 3: Section 4.1.2 is also changed.
<cferris> RESOLUTION: issue 4853 closed with Part a) from http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0017.html and proposal in two parts above
Abbie sounds tired
Paul: issue 4854
<cferris> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4854
Asir: editorial once choice decided
<paulc> Use /wsrmp:RMAssertion/@{any} instead of /samplePrefix:SampleAssertion/@any
Paul: notice the curlies!
... make sure there is appropriate reference to WS-RMP then
Phone just got disconnected, will dial in again
<asir> Updated editors' action to include WS-RM and WS-SecurityPolicy - http://www.w3.org/2005/06/tracker/wspolicyeds/actions/331
Paul: no objections to suggested changes
<cferris> RESOLUTION: issue 4854 closed with /wsrmp:RMAssertion/@{any} instead of /samplePrefix:SampleAssertion/@any
Asir: more issues open that use same assertions
<paulc> Meeting is rejoining the teleconference call.
Paul: item 3988
Chris: 3988 and 3989 go together
... 3989 is resolved by guidelines draft
<abbie> need to drive to work, will try to sign in in 1 hour
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jun/0095.html
Paul: skip, revisit when coming to 12 c)
... item 4695
<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jun/0095.html
Paul: process message 69 first
... skip for now
<paulc> e) ACTION-306 Review BP 23 and associated text, Section 5.7.
<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0009.html
Chris: does not understand current text, proposal to make it better understandable
Paul: explains suggested changes
Ashok: do we need to talk about precedence on assertion level or generically?
Maryann: There is generic guidelines in attachment
<cferris> new issue is http://www.w3.org/Bugs/Public/show_bug.cgi?id=4859
Maryann: This is a recommendation
Chris: Previous BP used term semantics
... trying to clarify that
<notlrahc> Chris: An assertion should mean what it means - a separate point - so we don't want to have language that allows changing the meaning
<paulc> RMPolicy: http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.html#_Toc160540908
<paulc> Consider adding example from http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.html#_Toc160540909
<paulc> Section 2.3 from RMPolicy could be used to illustrate this BP.
<notlrahc> fabian: In favour in principle, but don't like the use of 'precedence' - would be conflict if have same assertion attached across subjects
<paulc> Change "precedence rules" to just "rules" in BP title and text.
<cferris> RESOLUTION: close issue 4859 with proposal in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0009.html amended by adding an example reference to section 2.3 of wsrm policy (http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.html#_Toc160540909) and by removing the word "Precedence" from the phrase "precedence rules" in the original proposal
Paul: nobody else has concerns, proposals
Asir: missed one PR issue: 4851
Paul: next item
... action 304
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0010.html
Chris: summarizes proposal
Asir: take issues 4375 and 4376 together?
Frederick: hard to follow what we did if mixed together
Paul: I like to keep them separate, coming up next, can record conflict under subsequent items
Fabian: What is an XML outline?
Chris: can handle with next issue
Asir: integrate changes into 4661
<notlrahc> Asir: and 4662
Paul: proceed with 4661 and 4662
... item 4661
<paulc> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4661
Maryann: summarizes proposal
... Second example in 5.3.2 would disappear
Paul: 3 issues: 4661 (remove examples),
companion issue 4662 (add best practices), Chris proposal to change proposed
best practices
... Can we adopt all 3 of them?
Asir: Monica filed comments
Monica: comments part of 4695
<cferris> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jun/0078.html
Paul: Chris' email message #10
Monica: yes, have comments
Asir: comments in message #88
... on issue 4662
Paul: Asir comments in message #78
... point 3 in message above does not propose change, asks question
Maryann: explains point 3
Dave: Included in definition should be any attributes that affect intersection
Asir: what is the attribute?
Dave: any attribute that would affect intersection
Maryann: at a minimum, need to document
semantics of assertions
... included should be attributes that might affect intersection
Paul: I am collecting amendments and send them
as email
... point 4 in message 78
Maryann: Asir's suggestion is correct
... point 5
Paul: people confused by word "behavior"
Asir: suggests to drop sentence
Maryann: need to figure out how to explain attribute
Monica: can we handle that with action 324?
Asir: drop first sentence of 5.5.2
Maryann: OK
Paul: point 6
Monica: say "assertion authors should indicate semantics of intersection that allows ignorable attribute"
Paul: Asir, can you suggest a change?
Asir asks Maryann to explain intent of sentence
Asir: understands intent now
Paul: Regardless...
Maryann: Sounds good to me
Paul: point 7
Maryann: runtime behavior of the ignored assertions?
Asir: liked proposal in other message
<asir> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0007.html
<notlrahc> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0007.html
Monica: there is an amendment yet to be sent
Chris: What does lax intersection have to do with this?
Asir: My comment
... !
<notlrahc> Chris: This has nothing to do with the intersection mode in any case
Asir: can just drop sentence
Maryann: no
<notlrahc> Maryann: Excluded - that's what lax mode does
Chris: remove latter two paragraphs
Maryann: how are people supposed to understand how to use Ignorable?
<notlrahc> Maryann: This is the only thing that talks about ignorable behavior
Asir: not only section on Ignorable
Dave: Only section in guidelines
<notlrahc> That other section Asir mentioned is in the Primer
Paul: Wait for Monica to type proposal
<asir> Monica is typing her proposal - In the case where one party chooses to engage with another party based on policy alternatives resulting from a Framework intersection algorithm, the resulting policy could include a policy assertion marked as Ignorable. Whether or not that assertion is engaged is outside of the scope of the policy framework regardless if wsp:optional is used or not.
Paul: question from the chair: what text does this replace?
Monica: Replace where it starts "in the
case..."
... I did not address mode
Paul: by resulting policy you mean result of
intersection?
... no mentioning of mode
Asir: has comment on proposal
Chris: I am confused
... loosing context
Dave: work on details, then revisit the whole
Chris: Thinks changes go into wrong direction
Paul: Maryann believes section is essential
<notlrahc> Paul: [and DaveO]
Paul: Look at text after all changes were made
<notlrahc> Chris: IMHO how we're saying this is wrong
Chris: There may be assertions that have no behavior on other party, this text is starting from the wrong end
Maryann: discussed at last F2F
Paul: Asir, does change 5 reach your objective?
Asir: Last statement in Monica's suggestion on optional is incorrect
Dave: use compact form
Monica: OK with Dave
Chris: targeting wrong audience with this text
Paul: Asks Chris to write down changes
... need consensus how to make current text better
<notlrahc> Chris: Then I say what we initially had s/b used
Chris: don't agree with some other changes, too
Monica: Ignorable used in different ways. We don't know what happens.
Frederick: Should be clear if you know assertion can be Ignorable
<notlrahc> Maryann: This is trying to say that
Frederick: "regardless" is misleading
... add "if you know assertion can be ignorable, clarify that in your
definition"
... after regardless: "if there are reasons to allow this to be ignored, it
should be clearly stated in the assertion definition"
... Reword into better English
Asir: Paste Chris' text from 304
... cites Chris' change
Monica: does that take care of what happens after intersection
Frederick: we need both
Chris: what happened to discussion about intersection?
Maryann: is gone
<notlrahc> Paul: Current status...
Paul: folding suggestions into 4662
lunch break
<monica> test
<cferris> there is no such thing as an optional assertion
<cferris> or, perhaps, more correctly, every assertion is optional
<SergeyB> scribe: SergeyB
<monica> test
<Fabian> Star Wreck: In the Pirkinning - http://www.starwreck.com/
test
<scribe> scribe: Sergey Beryozkin
<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0010.html
<scribe> scribeNick: SergeyB
test
<notlrahc> scribe is SergeyB
Chris: is fine with the chnages to the recommnedation on the ignorable assertions, sections 5.5.1 and 5.5.2 in Guidelines
Ashok: minor grammar comment on section 5.5.1
PaulC: first paragraph is avout authoring, the second one with intersection
Chris: Intersection is nothing to do with authoring
Monica: 'handled' with respect to 'ignorable assertions' is better than .processed'
Ashok: agreed
Chris: lets make the sentence right, to convey the message properly
<dorchard> During intersection, there are two defined modes for processing, lax and strict. Policy assertions marked with an attribute to indicate that the assertion can be ignored by the interstection algorithm are processed differently by algorithms in strict and lax mode [see Framework and Primer for details] . Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersect
DavidO: Posted the paragraph we're all talking about
<dorchard> Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and indicate this in the definition of the assertion. The use of the ignorable attribute influences whether or not certain assertions are part of the compatability assessment between two alternatives.
<cferris> The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict) and an attribute (wsp:Ignorable) that can be added to an assertion to indicate that the assertion may be omitted from consideration in lax intersection [see Framework and Primer for details]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersect
<cferris> intersection, and should follow Best Practices 8 and 9 to include this guidance in the assertion's definition.
<cferris> The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be added to an assertion to indicate that the assertion may be omitted from consideration in lax intersection [see Framework and Primer for details].
Monica: ignoring assertion it's not for the compatibility matching
<dorchard> determining the compatibility of alternatives
Monica: the sentence in guidelines should be in line with the framework wording
<dorchard> to indicate that the assertion does not affect the determination of the compatibility of assertions during policy intersection
<cferris> The Framework also defines an attribute (wsp:Ignorable) that influences whether or not certain assertions are part of the compatability assessment between two alternatives.
<asir> looks okay
test
<paulc> The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives.
scribe /m2
test
<scribe> scribe: SergeyB
<scribe> scribeNick: SergeyB
test
<monica> test
ChrisL can we leave the paragragh 3 only in 5.5.1
Maryann: do we want a best guidance practice or just point authors to examples ?
PaulC: why we just don't remove '5.5.2
Ignorable behaviour at runtime' and let the text flow
... in 5.5.2 remove the paragraph 2
... Now that we've reached the concsensus, any comments on the 1st paragraph
in 5.5.2
Everyone: seems correct
PaulC: lets move to the 3rd paragraph in 5.5.2
Monica: we've talked with Maryann about
ignorable attributes
... you don't know about the ignorable assertions untill after the
compatibility matching
Maryann: once you have a resulting policy, then what you do with the ignorable assertions, if any, from a selection perspective, is out of scope
Monica: the client may choose to ignore the service or not based in the info conveyed by the ignorable assertion
Chris: Monica is saying that putting the ignorable attribute does not mean the marked assertion will be ignored
<cferris> Assertion Authors need to understand that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection are will ignore the assertion.
Chris: ignorable assertions does not mean the author can force the consumer to ignore it
<asir> We discussed this topic in April and May and agreed on the following text:
<asir> Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions.
<asir> In the Primer
Asir: one can refuse the words describing the ignorable assertions in the promer
<asir> http://www.w3.org/TR/2007/WD-ws-policy-primer-20070605/#strict-lax-policy-intersection
PaulC: lets point to the relevant section in the primer. 3.4.1
<dorchard> As said in Primer 3.4.1, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions."
DavidO: replace the second paragraph in section 5.5.2 from the related section in 3.4.1
Chris: this is not what Maryann tried to say
<cferris> Assertion Authors need to understand that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
PaulC: should one more sentence be added explaining the policy author whah happens next ?
<dorchard> the reader is gently reminded...
Chris: we need to make two points; ignorable assertions does not mean it will be ignored and if it's accepted by the consumer then it must not have wire affects
<cferris> I think that there are two points, possibly elucidated by 3 statements
PaulC: should we cover the lax mode too ?
<cferris> 1) reiterate the primer txt as proposed by david, then reinforce that for an assertion to be able to be marked as ignorable, it MUST not impose any wire-level requirements on the part of consumers
<dorchard> As said in Primer 3.4.1. "...". Therefore, any assertion that is marked with ignorable MUST not impose any wire-level requirements on the part of consumers.
<paulc> 2) Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
PaulC: I like the proposed 5.5.2 second paragraph
Ashok: I reckon the 1st paragraph in 5.5.2 is redundant
PaulC: I think we've processed Chris's Action
304
... we need to get back to 4662
... agreed on 5.5 section in guidelines
... proposal 4662 has 2 sections, we're done on the section about ignorable
assertions but not on the section about optional assertions
Monica: my comments were for 5.6.2
Maryann: Chris had a specific proposal about
XML outline and documentation for the ignorable attributes, we'd like to do
the same for optional attributes
... we'll 4 best practices and then we'll refer to them
PaulC: what we'll do with optional assertions guidelines is the same what we've done for guidelines for ignorable ones
Maryann: 4.6.6.1 is about making the general statement rather than having 4 best practice statements to avoid duplication
<paulc> Proposal for 4661/4662:
<paulc> 1. Adopt changes in 4661 taking into consideration the 4854 change for @any and the BP from Chris's ACTION-304.
<paulc> 2. Adopt change in 4662 taking into considertion the real time edits done on Jul 17 during the meeting (checked in CVS).
<paulc> 3. Adopt the change to the remaining text in 5.6.1 based on proposal from Monica in message Jun/0088.html
<cferris> RESOLTION: issue 4661 and 4662 closed with above proposal
<cferris> RESOLUTION: issue 4661 and 4662 closed with above proposal
<asir> related editors' action is at http://www.w3.org/2005/06/tracker/wspolicyeds/actions/336
<paulc> Issue 3988: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3988
<paulc> Issue 4663: http://www.w3.org/Bugs/Public/show_bug.cgi?id=4663
Asir: what Section8 talks about in guidelines
is widely covered in the primer
... over time we adopted the WWW Architecture document model
... so each of the section will do a problem statement and the example
... so section8 seems like the luxury given that we have examples
elsewhere
... one proposal 4663 - we add another subsection in the section 8, by
cutting and pasting from the WSA spec
... we'd better off linking to the relevant section in the primer
<monica> ping
<fjh> modify section 8 to be scenario with links to examples and sections elsewhere in document?
<fjh> is value of section 8 the scenario?
Maryann: we need a narrative describing how WSAddressing policy authors designed their assertions with relevant links
Ashok: would like to keep the examples, we should keep the section 8
Asir: the same examples are in the primer
Frederick: the value of keeping this section is
not clear
... what's the value of documenting the thought process WSA group went
through ?
Tom: the pain WSAaddressing group was so big that it would be helpful to show how they came to the right solution
<Zakim> DaveO, you wanted to respond to frederick on why..
Frederick: section8 would be really a practical use case description
Tom: can do a 2-page summary of the history of the WSA - WS Make Connection design decisions
DavidO: that can be useful
Asir: still not see what the value is
Felix: few people say it's valuable. would it make sense to have that 2-page history as a blog
PaulC: I like Tim Bray's Annotated XML
... something like that is useful but should we really do something like that
in guidelines ?
... should we rather spend time on polishing the guidelines
... I'm concerned about someone describing the mistakes of the other working
group
... that might imply that doing it all individually is easier
Tom: suggests writing a history and asking for the review