Geoff,
let me rephrase this in the form of a usecase that's been driving my
concerns/proposal. Let's pretend that Bob is made king of the world and
he turns WS-Enum into a recommendation tonight. Tomorrow I want to be
able to have my implementation of WS-Enum be able to advertise that it
supports XPath2. That's _tomorrow, not a year or more from now when some
standards org defines some QName, but tomorrow. I'm stuck on our proposal
because its the only way we could think of to solve this problem. If you
can find another way I'm very willing to consider it.
In a lot of ways this is similar to the Mode discussion. Its all about
composibility, usability and scalability. The idea of someone (whether
its a vendor or a customer) having all of the pieces of technology
available to them but not being able to use it because of some bureaucracy
would be really sad. "Bureaucracy" probably isn't the right word, but I'm
not sure what else to call it when people are blocked because of the lack
of a QName (or Mode URI) instead of code.
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.
Doug Davis/Raleigh/IBM@IBMUS
Sent by: public-ws-resource-access-request@w3.org
05/14/2009 08:49 PM
To
Geoff Bullen <Geoff.Bullen@microsoft.com>
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: [Bug 6403] Enumeration: define policy
I'm saying that if there's an expression language out there that can be
used as a filter dialect, I don't want to have to wait for a new spec to
be developed and standardized (just to give me a new QName) before I can
use it (like xpath2).
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 06:41 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
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.
> >
> >
> >
>