RE: [Bug 6403] Enumeration: define policy

Geoff writes:
"What if another company implements it without the XPATH2 element and 
advertizes the same policy?"

I, for one, would appreciate less use of ambiguous antecedents used in 
arguments.

If I understand the questions posed, (and I am not sure that I do) the 
first presumes that an endpoint is 
deployed that permits (rather than requires) filtering using the 
XPath2:FilterDialect. 

If that understanding is correct, then the answer to the first question 
is: of course it may.

As a reminder, the wsp:Optional='true' attribute is a short-hand policy 
authoring technique that yields a normal form
policy expression containing two policy alternatives, one with, and one 
without the policy assertion type that includes that 
attribute/value. Its purpose is to facilitate policy authoring. It says 
nothing about whether the implementation
of the endpoint that exposes that policy expression may choose to 
implement the behavior attributed  that 
assertion type.

As for the second question posed by Geoff, as to whether "another company 
implements it without...", if I understand
the intended nature of the question, he is asking whether another 
implementation may choose whether or not
to implement the behavior attributed to the XPath2:FilterDialect policy 
assertion type.

The answer to that second question is: if it did, that practice, of 
including a policy assertion type representing behavior
that is not implemented in one's published policy, would be really, 
really, really stupid. Technically, that would be 
lying about the capabilities of the deployed endpoint which would result 
in false positive matches during policy intersection
with the policy expressions of client endpoints that DID (legitimately) 
include XPath2:FilterDialect. It would
seem to me that publishing policy that intentionally yields false positive 
matches would defeat the whole point
of WS-Policy.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986





From:
Geoff Bullen <Geoff.Bullen@microsoft.com>
To:
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
Date:
05/13/2009 01:17 PM
Subject:
RE: [Bug 6403] Enumeration: define policy
Sent by:
public-ws-resource-access-request@w3.org



Doug,
Here is a simple example that we can look at.  The new XPath2 standard 
comes out and company X has an implementation of an Enumeration End Point 
that currently supports the current XPath. They choose to implement a new 
XPath2 filter message as :
<Enumerate>
  …
  <Filter Dialect="…/XPath2">
     <XPATH2>
           Xpath2 filtering syntax here
      </XPATH2>
    </Filter>
</Enumerate>
 
Company X is free to implement XPath2 filtering for their own end point in 
that way if they wish, but can they then use
<x:FilterDialect xmlns:x="…/Xpath2" wsp:Optional="true"/> as a policy 
statement to advertize it?  What if another company implements it without 
the XPATH2 element and advertizes the same policy?
 
--Geoff 
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, May 12, 2009 12:22 PM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 6403] Enumeration: define policy
 

I'm not sure I understand the question.  Someone can use (and interop) 
with xpath 2.0 and enum w/o a new spec - and the same can be true for some 
other expression language (not all are as complicated at xpath - e.g. the 
QName dialect in RT). The concern I have is whether or not it'll require a 
new spec just to define a QName to say that the data source supports it.   


thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 


Geoff Bullen <Geoff.Bullen@microsoft.com> 
05/12/2009 03:11 PM 


To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <
public-ws-resource-access@w3.org> 
cc

Subject
RE: [Bug 6403] Enumeration: define policy
 








Doug, for anything to be a “standard” there has to be some level of 
interop testing.  How do you propose to do interop testing on the new 
expression language usage with Enumeration? 
  
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, May 12, 2009 12:05 PM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 6403] Enumeration: define policy 
  

sure - but would it require any new text beyond what ws-en already says. 
I'm just not so sure and I'm worry about how heavy of a burden we're 
putting on people who end up wanting to use an expression language that 
doesn't require a whole new spec. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 

Geoff Bullen <Geoff.Bullen@microsoft.com> 
05/12/2009 03:02 PM 
 


To
Bob Freund <bob@freunds.com>, Doug Davis/Raleigh/IBM@IBMUS 
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
Subject
RE: [Bug 6403] Enumeration: define policy

 
 









Yes there are… 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Bob Freund
Sent: Tuesday, May 12, 2009 12:00 PM
To: Doug Davis
Cc: public-ws-resource-access@w3.org
Subject: Re: [Bug 6403] Enumeration: define policy 
 
Well, there are certainly semantic differences in several xpath operators 
between 1.0 and 2.0 
 
On May 12, 2009, at 2:43 PM, Doug Davis wrote: 



I'm not so sure.  For example, I'm not an XPath expert but would an XPath 
2.0 filter dialect need anything more than what's already stated for 
XPath? If not, is it really worth creating a new spec just for a QName? 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 

Geoff Bullen <Geoff.Bullen@microsoft.com> 
05/12/2009 02:19 PM 
 
 


To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <
public-ws-resource-access@w3.org> 
cc

Subject
RE: [Bug 6403] Enumeration: define policy


 
 
 









Hi Doug, 

On your first point, 
What seems to be being said here is that if a new YPath filtering standard 
comes along, and someone wants to use it with Enumeration, they will have 
to define the Policy Assertion, and potentially standardize it, if interop 
is an issue.  While, with the method proposed below, there is an “implied” 
policy because you can use: 

wsen:FilterDialect uri="…/YPath"/> 

This seems like a very dangerous assumption, in that there is no real 
definition for what is meant by using YPath as a filter dialect in 
Enumeration – it is just “assumed” to work the “way you think it should 
work”.  It seems that is would not be too hard to find examples of where 
two different implementations of the same filtering mechanism would 
produce different results under such circumstances.  It would be much 
safer to actually define (somewhere) what the interaction is between YPath 
and Enumeration and in the same place define the policy assertion 
associated with it.  Note that the YPath policy assertion could have extra 
extension attributes, where as the method below does not allow that (where 
would they be defined?). 


On your second point, 
This also ignores the possibility of extension attributes on policy 
assertions – all policy assertions would have to look and behave the same 
in order for the user interface to behave in such a generalized manner. Do 
you really think that users are going to type in raw filter expressions, 
possibly in XML, with no syntax checking on the client side?  Is this a 
real use case? 

--Geoff 

From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, May 12, 2009 9:37 AM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 6403] Enumeration: define policy 


Hi Geoff, 
This is actually really close to my proposal - it just changes the NS and 
localName of the QName - however, there are a couple of aspects of this 
solution that prevented me from picking this approach in my original 
proposal. 

First, this will probably require the definition of a 3rd spec for each 
filter dialect.  Let's take the case of XPath.  Let's assume that 
WS-Enumeration were already completed and behind us (and XPath wasn't 
known, as filter, at that time).  If someone wanted to use XPath (which 
has no knowledge of WS-Enum) with WS-Enum, then they would need to define 
(and standardize) this new QName.  This would require a new spec and its 
not clear to me who would take on this responsibility. If it didn't come 
through some org, like w3c, then do we run the risk of each domain 
creating their own QName for the same dialect?  This could hurt interop, 
cause confusion and cause us more work. 

Second, I'm wondering if we lose the ability for smart clients to be more 
dynamic because this requires the client to know about all QNames in 
advance.  When parsing the Policy the client would need to know which 
QNames were Filter dialects and which were "something else" (which btw it 
can ignore based on the wsp:Optional attribute). So, if the client wanted 
to present the user with a drop-down box and a list of filter dialects to 
choose from, they could only do it for Filters dialects that were hard 
coded into the system.  Without some way to know that some new QName were 
a Filter dialect, they would be a bit stuck.  In cases where the client 
system itself will need to act on these QNames I think its fair to assume 
that the client must know about each one - however, with Filter dialects 
the client doesn't actually need to act on them.  Its the service that 
does all of the work.  So, in a dynamic environment (like the drop-down 
case I mentioned above) its possible to prompt the user with a list of 
Filter dialect and an entry field (where they can type the expression) and 
the subscriber's client code never actually needs to know anything about 
the Dialect. 

This is why ideally I really wanted something like: 
     <wsen:FilterDialect uri="...."/> 
But of course this would require domain specific policy processing - which 
I don't think anyone wants.  :-) 

I think the mechanism in my proposal, while a bit unique, does provide the 
same functionality of your proposal but also covers the concerns I 
mentioned above. 
And, it shouldn't cost anything more w.r.t. code since in your proposal 
you're asking the client to know about the QNames in advance, and there's 
no reason why they couldn't know about the QNames using the form I 
proposed.  It just saves the trouble of having to create a new (3rd) spec 
to link WS-Enum with some expression language. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 

Geoff Bullen <Geoff.Bullen@microsoft.com> 
05/12/2009 11:51 AM 
 
 
 


To
Doug Davis/Raleigh/IBM@IBMUS 
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> 
Subject
RE: [Bug 6403] Enumeration: define policy


 
 
 
 










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], 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 Thursday, 14 May 2009 14:07:02 UTC