Web Services Policy Working Group -- 20 Dec 2006

davec: Does WSDL v1.1 allow extensibility in the same manner?
... Want to leave open as extensibility point. What QName?
... Use extension syntax rather than local name. Does this work as thought?

paulc: Respond to WSDL WG thread.

cferris: This relates to issue about scoping. Treat only attachment points as in our document.

<umit> +1 to Chris.

paulc: This is Issue 4045.
... Limited debate here.

fsasaki: WSDL WG may discuss tomorrow.

Issue 4045

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4045

http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0031.html

cferris: Only concerned with a URI syntax to address attach points that relate to those described in PolicyAttachments.
... Limit cycles.

<fsasaki> +1 to chris

paulc: Bug doesn't identify what document parts are applicable.

cferris: Address after general discussion.

daveo: What parts of WSDL v1.1 wouldn't be described?
... Allow element identifiers in WSDL v1.1 namespace and SOAP binding namespace, not HTTP or MIME.

<cferris> the set of defined attachment points is as follows:

<cferris> *

<cferris> Service

<cferris> *

<cferris> Endpoint

<cferris> *

<cferris> Binding

<cferris> *

daveo: Extension and policy - write document that say how attachments made.

<cferris> Binding Operation

<cferris> *

<cferris> Binding Fault

<cferris> *

<cferris> Binding Message Reference

<cferris> *

<cferris> Binding Fault Reference

<cferris> *

<cferris> Interface

<cferris> *

<cferris> Interface Operation

<cferris> *

<cferris> Interface Fault

<cferris> *

<cferris> Interface Message Reference

<cferris> *

<cferris> Interface Fault Reference

cferris: WSDL v1.1 not v2.0. Above list is for WSDL v2.0. Correct.

<paulc> Above list are the WSDL 2.0 attachment points.

cferris: Now WSDL v1.1.
... Attachment points

http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-attachment.html?content-type=text/html;%20charset=utf-8

cferris: Endpoint policy subjects have WSDL v1.1 elements to attach that subject.
... WSDL v1.1 element names
... 12

paulc: Only do policy subjects in Section 4?
... Service, endpoint, operation and message

<paulc> Service, endpoint, operation and message are the WSDL 1.1 attachment points

paulc: See Table 1 on our document. There are 16 rows - what needs to change?

cferris: Affects SOAP for example.

paulc: Port type is not one of the items.

fabian: endpoint made up of some of these are relevant attachment points.

paulc: Need some assistance here.

<cferris> wsdl11:service

<cferris> wsdl11:port

<cferris> wsdl11:portType

<cferris> wsdl11:binding

<cferris> wsdl11:portType/wsdl11:operation

<cferris> wsdl11:binding/wsdl11:operation

<cferris> wsdl11:message

<cferris> wsdl11:portType/wsdl11:operation/wsdl11:input

<cferris> wsdl11:portType/wsdl11:operation/wsdl11:output

<cferris> wsdl11:portType/wsdl11:operation/wsdl11:fault

<cferris> wsdl11:portType/wsdl11:operation

<cferris> wsdl11:binding/wsdl11:operation

cferris: Keep these above.
... Eliminate the others. Open an action item.

<toufic> actually type "ACTION:" don't forget the ":"

cferris: Limit to WSDL v1.1 is Section 4 in PolicyAttachments before opening action.

daveo: I don't have a feel for what is not in the set.

<paulc> I think the things to be eliminated would be:

<paulc> a) extension points

cferris: Extensibility points should be eliminated.

<paulc> b) defintions

<paulc> c) type definitions

cferris: These are not attachment points.

<paulc> d) element declaration

<m2> thanks paul

daveo: Need to have items that are to be excluded.

<paulc> e) message part

daveo: Work needs to be done.

cferris: There is no argument about defined attachment points.

paulc: Have added items.
... Close to what is being requested.
... See a-e.

daveo: No definitions? What about policy attachments for definitions?

fabian: The spec doesn't prohibit. It is not discussed however.

daveo: Someone could do it in WSDL v1.1.

cferris: Where are the semantics?

daveo: Could they refer to it. Our example has a definition.

umity: Fragment identifier vs. using mechanism to be able to designate attachment points.
... Latter doesn't preclude later extension.

<dorchard> See example 4-1, it has a policy as a child of definitions, so why not have an EI for it?

<sanka> ping

umity: Have to describe policy to definition. But we may not need to address that. Keep minimum. Do other later.
... Don't waste time on semantics when time is minimum.

<umity> I support Chris.

<fsasaki> +1 to Umit

fabian: Good suggestion.

daveo: Unsure if agree.

<fsasaki> ACTION: Chris to add the change proposal to Issue 4045 [recorded in http://www.w3.org/2006/12/20-ws-policy-minutes.html#action02]

<trackbot> Created ACTION-173 - Add the change proposal to Issue 4045 [on Christopher Ferris - due 2006-12-27].

'Canonical form for WSDL 1.1 Element Identifiers'

<Fabian> Umit has found closure in herself :-)

http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0028.html

paulc: Add definition.
... Suggestion by Jonathan Marsh and has been included.
... See Section 3.3.
... With XPointer and WSDL using syntax, does this jive?

<fsasaki> ACTION: David to See what XPointer are in line with WSDL and syntax [recorded in http://www.w3.org/2006/12/20-ws-policy-minutes.html#action05]

<trackbot> Created ACTION-174 - See what XPointer are in line with WSDL and syntax [on David Orchard - due 2006-12-27].

Support for operations with the same name

http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0065.html

daveo: This is difficult.

paulc: What is impact to support?

fabian: Current proposal doesn't accommodate.

paulc: What part of table?

fabian: (first glance) Binding and port type operation will be affected. Need to extend and qualify with operation name and add input/output messages.

daveo: Isn't it more than that?
... Have to have more - message reference etc. This is ugly.

<cferris> you could do wsdl11.portTypeOperation(<name>[1])

paulc: Open issue.

<cferris> or, you could just use xpath syntax

<scribe> ACTION: Fabian to open an issue related to operations with the same name. [recorded in http://www.w3.org/2006/12/20-ws-policy-minutes.html#action06]

<trackbot> Created ACTION-175 - Open an issue related to operations with the same name. [on Fabian Ritzmann - due 2006-12-27].

<cferris> note my own personal preference to just use xpath syntax and be done with it

daveo: Take element identifiers and make as parameters to the operation.
... Syntax example.....

<dorchard> wsdl11.portTypeOperation(portType/operation(portTypeMessageReference(portType/operation/message, portTypeMessageReference(portType/operation/message, portTypeMessageReference(portType/operation/message))

paulc: Add health warning.

<cferris> all of this is "syntactic sugar" that IMNSHO will only be useful in the brief interlude between the introduction of the syntax and the time when IDE's provide tooling that automagically does the right thing without exposing the gory details to developers

<m2> That is why I didn't type it.

<cferris> I mean, really... who manually edits wsdl these days?

<sanka> http://rafb.net/paste/ can be used for pasting ..

<cferris> do we really think that people will manually edit policy?!

paulc: Are we willing to accept that limitation? No comments.

<dorchard> portTypeMessageReference(portType/operation( portTypeMessageReference(portType/operation/message), portTypeMessageReference(portType/operation/message), portTypeMessageReference(portType/operation/message))

Issue 4041 (deferred)

Action 152 (changed)

daveo: Versioning of policy language addressed.
... Reviewed examples.
... Don't need example.
... Advisement - new section proposed to identify making versioning advisement.
... Add Section 3.8.1

umity: Dismissed utility of Ignorable for versioning.
... Didn't explain why it is not appropriate. Can you elaborate?

daveo: Utility of wsp16: Choice....Mark as ignorable. Describe what to put into message. Language provides descriptions. Therefore, because an older version of policy will be understood and new not so.
... Need to provide to alternatives with old and new, where consumer will choose.
... Ignorable doesn't help with this.

umity: Because of choice with other contained elements, optionality is on containing element and removes utility of use of Ignorable. Ignorable only removes choice element and isn't useful?

daveo: Yes.
... Client will get new construct or not.
... Related to service action not client.

danroth: The idea of adding versioning as policy assertion as Ignorable. That sounds fine. I have a concern however about recommending a policy assertion.
... We need more experience.

daveo: Should we soften the language?
... Soften to say this is one example of use.

<umity> i actually like the example included in the proposal. My question was more on the added constructs (like choice)

<umity> which issue are we on?

Issue 3980 The introduction section

<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2006Nov/0106.html

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3980

danroth: Understand WS-Policy Framework and point to Primer.

cferris: Reviewed documents. Raise issue about wsdl 1.1, SOAP and other references. What about WSDL v2.0 etc.

<dorchard> would prefer no version #s.

cferris: Be more generic?

paulc: Is this concern orthgonal to this proposal?

cferris: Not really.
... Still has an impact. This sentence is going in the wrong direction.
... We should point to the normative documents.

<maryann> +1

<paulc> This document assumes a basic understanding of XML, Namespaces in XML, WSDL, SOAP and the Web Services Policy language. Web Services Policy 1.5 - Primer provides an introductory description of the Web Services Policy language.

<dorchard> 'This document assumes a basic understanding of XML, Namespaces in XML, WSDL, SOAP and Web Services Policy.

paulc: Does this meeting your requirements?
... "This document assumes a basic understanding of XML, Namespaces in XML, WSDL, SOAP and the Web Services Policy language. Web Services Policy 1.5 - Primer provides an introductory description of the Web Services Policy language."

daveo: Prefer not to use version numbers.

<maryann> i disagree with why the primer is called out beyond the policy language

<maryann> +1

daveo: Disagree perhaps with second sentence.

<cferris> +1

paulc: Does Guidelines include references?

umity: References exist.
... Explicit references exist if used.

<umity> +1 to Dave

daveo: Can live with proposed text.

maryann: Agree with cferris. Can't live with second sentence.

<dorchard> Prefer my proposed text, and can live with PaulC's proposed text

maryann: Specifications are the descriptions.

<cferris> I support daveo's proposed text

<paulc> Proposal: This document assumes a basic understanding of XML, Namespaces in XML, WSDL, SOAP and the Web Services Policy language

paulc: Proposed text above.
... Agreed

cferris: Will close Issue 3980.

<cferris> RESOLUTION: Issue 3980 is closed with the resolution: replace the sentence highlighted in the issue with: "This document assumes a basic understanding of XML, Namespaces in XML, WSDL, SOAP and the Web Services Policy language."

Issue 3983 The Guidelines document should use a phrase to identify the target audience consistently.

<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2006Nov/0108.html

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3983

danroth: Different terms to talk about assertion authors.

c/authors./authors used.

<dorchard> +1 to Asir/Dan's proposal.

danroth: Use 'assertion authors.'

maryann: "WS-Policy assertion authors" should be used.
... Leave to editors to decide where to change.

danroth: Use 'Policy assertion authors.'
... Drop 'WS' part.

maryann: Agreed.

<paulc> http://www.w3.org/TR/2006/WD-ws-policy-20061117/#policy_assertion

<cferris> +1 to Dan... there is no WS-Policy term used in the normative specs

<maryann> yes

daveo: Like 'policy assertion authors' but prefer 'assertion authors. We know the scope of this document too.

<paulc> Chris please add Frederick to the roll call.

daveo: Can live with 'policy assertion authors.'

frederick: Agreed. Put this at the introduction of the document.

maryann: Leave to editors.
... Need common statement.

paulc: Put definition at the beginning and then use 'assertion authors' throughout.

<dorchard> something like, assertion authors (formally, an author of a "policy assertion")..

RESOLUTION: Issue 3983 is closed by placing definition at the beginning for 'policy assertion authors' and then use 'assertion authors' throughout.

Issue ISSUE 3984 Assertion Parameters vs. Name Value Pairs

<paulc> Issue 3984

<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2006Nov/0109.html

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3984

<dorchard> +1 to proposal.

danroth: Name value pairs used to create a policy assertion inferred.
... Replace with assertion parameters and get rid of 'for example.'

<paulc> policy assertion parameters defn:

<paulc> http://www.w3.org/TR/2006/WD-ws-policy-20061117/#policy_assertion_parameter

<dorchard> or even: assertion parameters (for example name value pairs)

danroth: Suggest we remove 'for example' and replace name value pairs with 'assertion parameters'.

paulc: Does name value pairs exist anywhere?

<danroth> Here is my ammended proposal:

<danroth> The framework allows WS-Policy domain authors to define policy assertion parameters to

<danroth> qualify an assertion

daveo: Associate parameter with name value pair.

<maryann> +1 to dan

<paulc> The framework allows WS-Policy domain authors to define policy assertion parameters to qualify an assertion.

umity: Statement doesn't appear in the current document.

<umity> If the assertion is a parameterized assertion the authors must understand that this type of assertion will require additional processing by consumers in order to disambiguate the assertions or to understand the semantics of the name value pairs, complex content, attribute values contribution to the processing.

umity: Current statement is in Section 4.4.3 (no 'for example').

from document: "If the assertion is a parameterized assertion the authors must understand that this type of assertion will require additional processing by consumers in order to disambiguate the assertions or to understand the semantics of the name value pairs, complex content, attribute values contribution to the processing. "

<umity> +1 Frederick

<danroth> http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.8&content-type=text/html;%20charset=utf-8#parameterized-assertions

frederick: Need to deal with name value pair regardless of full text.

<dorchard> need to drop off now..

danroth: Was in Section 4.4.1.
... That text has been updated.

<danroth> The framework allows WS-Policy domain authors to define parameters, for example, to qualify an assertion

<FrederickHirsch> we can allow editors to determine the exact wording

danroth: Also occurs in Section 4.4.3. Do general cleanup to use policy assertion parameters.

paulc: Clarify proposal.

umity: Separate issue?

<paulc> The framework allows WS-Policy domain authors to define plicy assertion parameters, for example, to qualify.

<paulc> The framework allows WS-Policy domain authors to define plicy assertion parameters.

Scribe is confused.

<danroth> The framework allows WS-Policy domain authors to define policy assertion parameters to qualify an assertion.

paulc: Current CVS here. Part 1

<paulc> a) Section 4.4.1: The framework allows WS-Policy domain authors to define policy assertion parameters to qualify an assertion.

paulc: Section 4.4.1 as above.

<paulc> b) Cleanup to eliminate "name value pair".

paul: Clean up to eliminate name value pair.

<cferris> I think it is more like b) s/name value pair/policy assertion parameter/g

monica: Need to be consistent with previous issue on name of author.

<paulc> a) The framework allows assertion authors to define policy assertion parameters to qualify an assertion

paulc: updated proposal for a).

RESOLUTION Issue 3984 is closed to:

a) Section 4.4.1: The framework allows policy assertion authors to define policy assertion parameters to qualify an assertion.

b) Change name value pair with policy assertion parameters.

<paulc> Issue 3953

<paulc> http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0066.html

3953 - Remove language that use of security policy assertions forces nested assertions for other domains.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953

frederick: Change paragraph as specified in link: http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0066.html

paulc: Text talks about core assertions as a new phrase.

frederick: Talk in natural language. Intent to say WS-SecurityPolicy defines basics.
... Could delete 'core' in two occurrences.

<cferris> it would be my receommendation to s/core// in the proposed text

danroth: Phrase 'since any domain....understand implications..." From the text it is unclear what the implications are (not specified and what to do).
... If we raise a flag, we need to explain issue and how to deal with it.

<maryann> +q

frederick: Don't necessarily agree but understand your point.
... Guidelines can't provide a tutorial to accomplish this.

cferris: Don't know what core assertion is. Suggest remove the term (as Frederick suggested).
... Agree with Dan secondly - what is the mitigation?
... Security domain is not necessarily the only domain applicable here.
... Relationships could be endless.
... Try to insure assertions are standalone.

paulc: What was the intent?

frederick: Original concern was nested assertions with multiple domains. Conclusion, there is no requirement to do so.

cferris: Example is unusual then.

frederick: No nesting is happening and text deleted.
... Have extensions - security policy and then reliable messaging adds additional restrictions.
... Requires you understand both.

<cferris> I would note that the reference to the RM Policy spec in the issue is incorrect... it returns a 404

<cferris> the correct link is: http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html

cferris: Domain like reliable messaging with implications to security. In composition, these should be considered?

maryann: Need to give an example such as this.
... Need to address composite set.
... Liked proposed text and want specifics on why it is not preferred?

frederick: RM defines two assertions related directly to security. They need to be compatible with security.
... Need to be consistent.

umity: We are no longer advocating nesting and this should be clear.
... We are trying to accommodate composition and the domain composing with, understanding the implications.

danroth: Last sentence on nesting was removed - good.
... On relationship between RM and security, does it target those domains specifically? Discourage duplication of assertions?
... Be more generic with this as an example?

cferris: RM makes use of security assertions. Leave out WS-SecurityPolicy.

<umity> Chris, why don't you write a counter proposal ?

<umity> ...and just write it down ?

maryann: Dan it isn't just duplicating but extensibility too.

<cferris> Domain authors need to be clear about the relationship of assertions defined

<cferris> in their domain and assertions for another interrelated domain. The classic example

<cferris> of such an interrelated domain is security, because security tends to cut across

<cferris> all aspects of a solution. One example is the definition of additional assertions related to

<cferris> security in Web Services Reliable Messaging Policy Assertions [WSRMP].

<cferris> [WSRMP] http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html

<cferris> actually, I just noticed something still not quite right

frederick: Agree with Chris information and editorially combine with our proposal.

<cferris> Domain authors need to be clear about the relationship of assertions defined

<cferris> in their domain and assertions for another interrelated domain. The classic example

<cferris> of such an interrelated domain is security, because security tends to cut across

<cferris> all aspects of a solution. One example is the use of assertions related to

<cferris> security [WS-SecuirityPolicy] in Web Services Reliable Messaging Policy Assertions [WSRMP].

<cferris> [WSRMP] http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-rddl-200608.html

<umity> oops

<umity> i will dial back in

<umity> Chris the text is not quite right

danroth: Last sentence should be removed; it is a domain-specific recommendation.

<maryann> i just want to assert again that the issue is not just duplicating assertions, but also extending the semantics of another domain and whether or not you need to follow recommendations of extensibility for the related domain

danroth: Relationship is confusing to me.
... Don't know what relationship we are highlighting.

cferris: Agree with Roth. Clear with intent and need just to realign text.
... Work with Umit and Frederick on revised proposal.

<danroth> I would be fine if the last sentence in the proposal was an example of a more general recommendation

<maryann> so i would like this resolution to address the question of whether or not one domain can extend the semantics of another domain

cferris: Guidance about ensuring that what is specify in composition not conflict with base specification needs to be there.

<danroth> +1 to cferris

c/specify/specified

<scribe> ACTION: Frederick to revise proposal to accommodate Chris Ferris' ideas. Umit to assist. Issue 3953. Coordinate with MaryAnn and Chris Ferris. [recorded in http://www.w3.org/2006/12/20-ws-policy-minutes.html#action08]

<trackbot> Created ACTION-176 - Revise proposal to accommodate Chris Ferris\' ideas. Umit to assist. Issue 3953. Coordinate with MaryAnn and Chris Ferris. [on Frederick Hirsch - due 2006-12-27].

paulc: Happy Holidays.
... Next meeting 3 Jan - agenda to follow.

Web Services Policy Working Group
20 Dec 2006

Attendees

Contents

F2F January 2007

Editorial team report

WSDL v1.1 Identifiers

Review action items.

Issue 4045

'Canonical form for WSDL 1.1 Element Identifiers'

Support for operations with the same name

Issue 4041 (deferred)

Action 152 (changed)

Issue 3980 The introduction section

Issue 3983 The Guidelines document should use a phrase to identify the target audience consistently.

Issue ISSUE 3984 Assertion Parameters vs. Name Value Pairs

3953 - Remove language that use of security policy assertions forces nested assertions for other domains.

Summary of Action Items

Web Services Policy Working Group 20 Dec 2006

Attendees

Contents

F2F January 2007

Editorial team report

WSDL v1.1 Identifiers

Review action items.

Issue 4045

'Canonical form for WSDL 1.1 Element Identifiers'

Support for operations with the same name

Issue 4041 (deferred)

Action 152 (changed)

Issue 3980 The introduction section

Issue 3983 The Guidelines document should use a phrase to identify the target audience consistently.

Issue ISSUE 3984 Assertion Parameters vs. Name Value Pairs

3953 - Remove language that use of security policy assertions forces nested assertions for other domains.

Summary of Action Items

Web Services Policy Working Group
20 Dec 2006