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.
> >
> >
> >
>
>