Re: [Bug 6403] Enumeration: define policy

Doug:
XPath 2.0 is a significant change from XPath 1.0. For one, it is Schema 
aware so it recognizes various datatypes
and provides many, many functions to operate on/test those datatypes.
It is, though, a new spec and may not have enough uptake just yet but we 
should provide extensibility to allow for it in future versions.
All the best, Ashok


Doug Davis wrote:
>
> I don't understand why they would even think to put the XPath2 element 
> in there. That element is not defined by the 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/13/2009 01:15 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,
> 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_ <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Geoff Bullen <**_Geoff.Bullen@microsoft.com_* 
> <mailto:Geoff.Bullen@microsoft.com>*>*
>
> 05/12/2009 03:11 PM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, "_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>" 
> <_public-ws-resource-access@w3.org_ 
> <mailto: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> 
> _[mailto:public-ws-resource-access-request@w3.org]_ 
> <mailto:%5Bmailto:public-ws-resource-access-request@w3.org%5D> *On 
> Behalf Of *Doug Davis*
> Sent:* Tuesday, May 12, 2009 12:05 PM*
> To:* _public-ws-resource-access@w3.org_ 
> <mailto: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_ <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Geoff Bullen <**_Geoff.Bullen@microsoft.com_* 
> <mailto:Geoff.Bullen@microsoft.com>*>*
>
> 05/12/2009 03:02 PM
>
> 	
>
>
> To
> 	Bob Freund <_bob@freunds.com_ <mailto:bob@freunds.com>>, Doug 
> Davis/Raleigh/IBM@IBMUS
> cc
> 	"_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>" 
> <_public-ws-resource-access@w3.org_ 
> <mailto: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> 
> _[mailto:public-ws-resource-access-request@w3.org]_ 
> <mailto:%5Bmailto:public-ws-resource-access-request@w3.org%5D> *On 
> Behalf Of *Bob Freund*
> Sent:* Tuesday, May 12, 2009 12:00 PM*
> To:* Doug Davis*
> Cc:* _public-ws-resource-access@w3.org_ 
> <mailto: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_ <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Geoff Bullen <**_Geoff.Bullen@microsoft.com_* 
> <mailto:Geoff.Bullen@microsoft.com>*>*
>
> 05/12/2009 02:19 PM
>
> 	
>
>
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, "_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>" 
> <_public-ws-resource-access@w3.org_ 
> <mailto: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> 
> [_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_ 
> <mailto: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_ <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>
> *Geoff Bullen <**_Geoff.Bullen@microsoft.com_* 
> <mailto:Geoff.Bullen@microsoft.com>*>*
>
> 05/12/2009 11:51 AM
>
> 	
>
>
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	"_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>" 
> <_public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>>, 
> "_public-ws-resource-access-request@w3.org_ 
> <mailto:public-ws-resource-access-request@w3.org>" 
> <_public-ws-resource-access-request@w3.org_ 
> <mailto: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 _* 
> <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> 
> [_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_ 
> <mailto:public-ws-resource-access@w3.org>; 
> _public-ws-resource-access-request@w3.org_ 
> <mailto: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>
> > [_mailto:public-ws-resource-access-notifications-request@w3.org_] On
> > Behalf Of _bugzilla@wiggum.w3.org_ <mailto:bugzilla@wiggum.w3.org>
> > Sent: Tuesday, April 21, 2009 1:39 PM
> > To: _public-ws-resource-access-notifications@w3.org_ 
> <mailto: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_ 
> <mailto: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 00:27:25 UTC