W3C home > Mailing lists > Public > public-ws-policy@w3.org > August 2006

RE: NEW ISSUE: Semantics of successful intersection determined by domain-specific assertion content

From: Daniel Roth <Daniel.Roth@microsoft.com>
Date: Wed, 30 Aug 2006 10:58:35 -0700
Message-ID: <CACD2E414F77164CA4F324AF9A2094F3025EF909@RED-MSG-70.redmond.corp.microsoft.com>
To: "Glen Daniels" <gdaniels@sonicsoftware.com>, <public-ws-policy@w3.org>

Hi Glen,

Below you mention that "there are potentially serious interoperability
concerns here..."  Could you please elaborate on this point?  What are
the interoperability issues and how do you think they would play out?

Thanks.

Daniel Roth

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Glen Daniels
Sent: Wednesday, July 12, 2006 7:57 PM
To: public-ws-policy@w3.org
Subject: NEW ISSUE: Semantics of successful intersection determined by
domain-specific assertion content



Description:

Section 4.4 of the WS-Policy spec [1] states that domain-specific
processing may need to be performed in order to determine the
intersection of two policies.  This means that generic Policy processors
(tools, etc) cannot have any guarantee of successfully calculating the
intersection without appropriate extensions/plugins being available for
all domain-specific assertions.

Justification:

There are potentially serious interoperability concerns here, since
building a general-purpose Policy processor which reliably computes
intersections is impossible without some indication that assertions do
(or do not) augment the semantics.

Proposal:

The solution space here seems to work out like this -

1) Leave it as-is.

2) Remove the ability for domain-specific logic to affect intersection,
and only use top-level QName matching.  This would simplify the
algorithm and allow interoperability, but at the cost of disabling some
powerful functionality for domain authors.

3) Since WS-Policy is a generic framework, it should be possible to at
least *know* when particular assertions are going to affect the
intersection semantics.  It would be fairly easy to have a "wsp:custom"
(not necessarily the best name) attribute on assertions, which when
"true" would indicate that the marked assertion does alter/augment
intersection semantics.  In that case, the processor would be able to
recognize when it has the correct plugins, and when it cannot deliver a
reliable intersection.  This is analagous to soap:mustUnderstand and
wsdl:required - an indication that an extension may change the rules in
ways that must be agreed upon for success.

I therefore propose we begin discussion, with a preference to explore
solution #3.

Thanks,
--Glen

[1] http://www.w3.org/Submission/WS-Policy/#Policy_Intersection
Received on Wednesday, 30 August 2006 17:59:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:40 GMT