W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > May 2009

RE: [Bug 6403] Enumeration: define policy

From: Geoff Bullen <Geoff.Bullen@microsoft.com>
Date: Tue, 12 May 2009 08:51:43 -0700
To: Doug Davis <dug@us.ibm.com>
CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
Message-ID: <5AAAA6322448AA41840FC4563A30D6E847585C6289@NA-EXMSG-C122.redmond.corp.microsoft.com>

We propose the following as clarifying amendments to Doug's proposal for Issue 6403:
--Geoff
The Policy assertion for the XPath filter dialect

<wsen:XPathFilterDialect wsp:Optional? />

/wsen:XPathFilterDialect
The policy assertion represents a requirement to include an XPath filter in the WS-Enumeration implementation found at this end point and, specifically, that the attribute: [Body]/wsen:Enumerate/wsen:Filter/@Dialect=" http://www.w3.org/TR/1999/REC-xpath-19991116 " MUST be specified in wsen:Enumerate messages sent to this Web Service.

/wsen:XpathFilterDialect/@wsp:Optional="true"

Per Web Services Policy [WS-Policy]<http://www.w3.org/TR/soap12-mtom-policy/#WS-Policy>, this is compact notation for two policy alternatives, one with and one without the assertion. This indicates that the behavior indicated by the assertion is optional, specifically that a message without an filter dialect is also supported by the endpoint.
/wsen:XPathFilterDialect/@any
This is an extensibility mechanism to allow additional attributes to be added to the element.

The XPathFilterDialect policy assertion element information item MUST NOT include the  wsp:Ignorable attribute in its [attributes] property.
A policy expression containing the XPathFilterDialect policy assertion MUST, if present be attached to either a wsdl:binding/wsdl11:binding or wsdl:endpoint/wsdl11:port.
The normative outline for the Enumeration assertion would be:
<wsen:WSEnumeration [wsp:Optional="true"]? ...>
  <wsp:Policy>
    <wsen:XPathFilterDialect [wsp:Optional="true"]? />
    ...
  </wsp:Policy>
</wsen:WSEnumeration>



From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Monday, April 27, 2009 10:07 AM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: [Bug 6403] Enumeration: define policy


Geoff wrote:
> In general, we are OK with your proposal for Issue 6403.  Here are
> our general comments on the proposal.  I will be happy to provide
> more concrete suggestions in a subsequent email as we are heads-down
> processing multiple WS-RA issues at the moment.
>
>
> A)   The <x:FilterDialect> is not a concrete policy assertion but a
> template. This is the first of a kind. How can the WS-RA WG provide
> an XML Schema definition to specify the syntax of the assertion?
> Why not just define a policy assertion for the XPath filter dialect?

Can you give an example of what you're thinking of?  I think its important
to do the policy matching w/o needing domain specific code so I'd be
curious to see what you have in mind.

> We do not understand what is the justification of the statement:
>    "the namespace of this element is application defined, but the
> Local Name MUST be "FilterDialect""
> Why is element matching not using namespaces here?

It _does_ use element matching - so I'm not following.

> >/wsenp:WSEnumeration/wsp:Policy/x:FilterDialect@wsp:Optional
>   This attribute specifies that the assertion is optional per WS-
> Policy. This attribute MUST be present
>
> B)   The proposal mandates the use of wsp:Optional attribute. But
> the minimum here would be to allow the use of the attribute and
> defer the usage of it to service providers.

We can change this, but my thinking was that the use of the Filter
element and any particular filter dialect (even if just one is
supported) is optional for the client.  But we can change this
if people want and assume people are going to be smart enough
to know that they should really include it - esp. when they support
more than one dialect.

> C)   Would it be useful to check if the proposed assertion follows
> the best practices outlined in the 'Web Services Policy 1.5 -
> Guidelines for Policy Assertion Authors' doc [1].
>
> At a glance, it appears that the proposal does not follow best
> practices 6, 8, 9, 15, 20, 29 and 31.

Feel free to do so, but the only one that seems interesting is
29 and I think I got that covered, but we can use more WSDL-specific
wording if needed.

> --Geoff
>
>
> [1] http://www.w3.org/TR/2007/NOTE-ws-policy-
> guidelines-20071112/#best-practices-list
>
>
> -----Original Message-----
> From: public-ws-resource-access-notifications-request@w3.org
> [mailto:public-ws-resource-access-notifications-request@w3.org] On
> Behalf Of bugzilla@wiggum.w3.org
> Sent: Tuesday, April 21, 2009 1:39 PM
> To: public-ws-resource-access-notifications@w3.org
> Subject: [Bug 6403] Enumeration: define policy
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6403
>
>
>
>
>
> --- Comment #4 from Robert Freund <bob@freunds.com>  2009-04-21 20:38:56 ---
> modified proposal as above with the following:
>
> insert after :/wsenp:WSEnumeration/wsp:Policy/x:FilterDialect
> An endpoint should include a filterdialect policy assertion for each of the
> filter dialects that it supports.
>
>
> --
> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug.
>
>
>
Received on Tuesday, 12 May 2009 15:52:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:00 GMT