Re: [Bug 6403] Enumeration: define policy

 > Wouldn’t this mean that this policy assertion is being automatically 
added to the XPath2 namespace?
No, it identifies the filter dialect as being XPath2.

All the best, Ashok


Geoff Bullen wrote:
>
> Thanks for the clarification Doug.
>
> <x:FilterDialect xmlns:x=".../XPath2"/>
>
> Wouldn’t this mean that this policy assertion is being automatically 
> added to the XPath2 namespace?
>
> What if the “…/Xpath2” namespace already includes FilterDialect?
>
> More generally, are you not saying that if someone can think of a 
> reason why they might use a particular spec A as a filter for 
> Enumeration or Eventing, then automatically there is now a new policy 
> assertion defined in spec A’s namespace?
>
> This appears problematic because:
>
> 1. You are adding something to a namespace owned and controlled by 
> someone else.
>
> 2. What about collisions?
>
> 3. There is no way to define or test conformance to this assertion.
>
> 4. There is no schema associated with this.
>
> Hope this helps,
>
> Geoff
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
> Davis
> *Sent:* Thursday, May 14, 2009 9:06 AM
> *To:* public-ws-resource-access@w3.org
> *Subject:* RE: [Bug 6403] Enumeration: define policy
>
>
> At the risk of adding more confusion, neither :-)
>
> My proposal is that the assertion would be:
> <xFilterDialect xmlns:x=".../XPath2"/>
>
> the namespace URI of the element is the URI that goes into the Filter 
> Dialect attribute. This allows for a generic piece of code to know 
> which assertions are filter dialects (instead of something else) and 
> to know exactly what the URI for the attribute would be.
>
> Having a URI attribute (like both of your alternatives show) would (I 
> believe) lead to domain specific processing for policy matching - and 
> that's something I think we should avoid.
>
> 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/14/2009 11:59 AM
>
> 	
>
> To
>
> 	
>
> Doug Davis/Raleigh/IBM@IBMUS, "ashok.malhotra@oracle.com" 
> <ashok.malhotra@oracle.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>
>
> Subject
>
> 	
>
> RE: [Bug 6403] Enumeration: define policy
>
>
> 	
>
>
>
>
> Doug,
> Perhaps the actual policy assertions for the Xpath2 policy assertions 
> would be helpful here. Our understanding is that your proposal states 
> the assertion has the form:
> <x:FilterDialect uri="...." />
>
> (Note: “optional=true” is left out from all the assertions to make 
> them shorter)
>
> Using the XPath2 example below, which assertion does this map to for 
> your proposal?
> 1) <wsen:FilterDialect uri=".../XPath2" />
> or
> 2) <mynamespace:FilterDialect uri=".../XPath2" />
>
> The arguments presented appear to imply you mean option 1) as you 
> argue that the policy assertion would represent a “standard way” for 
> any end point to assert that it supports the XPath2 filter dialect. 
> Note the use of “wsen:FilterDialect”.
>
> If option 2) was correct, there would still be no “standard” known 
> definition for the new XPath2 assertion as you could not assume that 
> <a:FilterDialect uri=".../XPath2" /> and <b:FilterDialect 
> uri=".../XPath2" /> are the same assertion. This appears to have 
> little value over using “<a:XPath2FilterDialect />”.
>
> Option 1) implies that a new standard assertion is automatically added 
> to the WS-Enumeration namespace whenever a new “filter” dialect (for 
> example XPath2) is standardized. While the reasoning behind wanting 
> this is clear, as stated below this does have interop implications, 
> and also seems to break the rule that extensions should not use the 
> standard namespace.
>
> --Geoff
>
>
> *From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Wednesday, May 13, 2009 5:37 PM*
> To:* ashok.malhotra@oracle.com*
> Cc:* Geoff Bullen; public-ws-resource-access@w3.org; 
> public-ws-resource-access-request@w3.org*
> Subject:* Re: [Bug 6403] Enumeration: define policy
>
>
> Ashok,
> I think you misunderstood my reply to Geoff. I'm not saying we 
> shouldn't allow XPath2.0 - what I'm saying is that I don't understand 
> why the <XPATH2> element from Geoff's example would be in there when 
> it doesn't appear to be part of the XPath 2.0 expression language.
>
> Geoff,
> you seem to be implying that new specs will need to be created to 
> build a link between Enum and some expression language. I wanted to 
> make sure you understood that people can still do that. There is 
> nothing stopping them from doing so. All they would need to do is 
> define a new namespace URI for that spec and viola, they have their 
> Enum filter dialect assertion. So my proposal allows for both worlds.
>
> 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.
>
> *ashok malhotra <ashok.malhotra@oracle.com>*
> Sent by: public-ws-resource-access-request@w3.org
>
> 05/13/2009 08:27 PM
>
> Please respond to
> ashok.malhotra@oracle.com
>
> 	
>
> To
>
> 	
>
> Doug Davis/Raleigh/IBM@IBMUS
>
> cc
>
> 	
>
> Geoff Bullen <Geoff.Bullen@microsoft.com>, 
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
>
> Subject
>
> 	
>
> 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 23:01:26 UTC