RE: RE: RE: [NEW ISSUE] 4561 clarification of domain-specific processing

Scrapping from this Wednesday WG conference call minutes and assembling based on what I heard, the two proposed changes are:

a) Change 1 [Replace the second paragraph in Section 4.5 with]:

"As a first approximation, an algorithm is defined herein that approximates compatibility in a domain-independent manner. Mechanisms for determining assertion parameter compatibility are not part of the domain-independent policy intersection. Determining whether two policy assertions of the same type are compatible may involve domain-specific processing for purposes of determining assertion parameter compatibility. Domain-independent policy intersection may be extended to include domain-specific processing. If a domain-specific intersection processing algorithm is required this will be known from the QName of the specific assertion type involved in the policy alternative. However, regardless of whether an assertion's QName indicates domain-specific processing, an implementation of the domain-independent intersection need not apply the domain-specific processing.

The domain-independent policy intersection is:"

b) Change 2 (drop the phrase "part of other"):

s/Assertion parameters are not part of the compatibility determination defined herein but may be part of other, domain-specific compatibility processing./Assertion parameters are not part of the domain-independent compatibility determination defined herein but the domain-independent policy intersection may be extended to include domain-specific processing for purposes of determining assertion parameter compatibility./

Regards,

Asir S Vedamuthu
Microsoft Corporation




-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Wednesday, June 06, 2007 8:17 AM
To: Christopher B Ferris; public-ws-policy@w3.org
Subject: RE: RE: [NEW ISSUE] 4561 clarification of domain-specific processing


Continuing the F2F discussion ...

If two policy alternatives are compatible, domain-specific intersection rules may render them incompatible (via assertion parameter compatibility processing). And, if two policy alternatives are not compatible, domain specific intersection cannot result in them being compatible. That is, the domain specific intersection rules, if any, are stricter than the QName based approximation in Section 4.5.

The policy intersection returns positives, false positives and negatives. The policy intersection does NOT return false negatives. This is important to key scenarios. At the Ottawa F2F, BEA/Dave outlined a scenario. Here is another scenario.

Consider a crawler that walks through a directory of services to identify candidate services that a requestor would consider interacting with. The crawler uses the policy intersection WITHOUT any domain specific code modules to discover the candidate services. The requestor further refines the candidates using the policy intersection WITH domain specific code modules, if any.

In the above scenario, if the policy intersection were to produce false negatives the requester would not have considered those services and the policy intersection would not be useful as a level one filter.

As discussed at the Ottawa F2F, several participants suggested clarifying this point in Section 4.5. We request the WG to consider the following clarification:

[Replace the second paragraph in Section 4.5 with the following]

"Mechanisms for determining assertion parameter compatibility are not part of the policy intersection and may be part of domain-specific compatibility processing (specific to the assertion type).

Because the assertion parameter compatibility is not part of the policy intersection, determining whether two policy assertions of the same type are compatible generally involves domain-specific processing. If a domain-specific intersection processing algorithm is required this will be known from the QName of the specific assertion type involved in the policy alternatives.

As a first approximation, an algorithm is defined herein that approximates compatibility in a domain-independent manner:"

Regards,

Asir S Vedamuthu
Microsoft Corporation


-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Tuesday, May 22, 2007 12:55 PM
To: Christopher B Ferris; public-ws-policy@w3.org
Subject: RE: [NEW ISSUE] 4561 clarification of domain-specific processing


Hi Chris,

I think you asked me this question when the WG was discussing the proposed non-matching example for Section 4.5. I misheard and misspoke. I did not see your question on IRC then.

The text in Section 4.5 says -

"If a domain-specific intersection processing algorithm is required this will be known from the QNames of the specific assertion types involved in the policy alternatives."

and

"Assertion parameters are not part of the compatibility determination defined herein but may be part of other, domain-specific compatibility processing."

If a domain were to leverage the policy intersection in the framework and specify domain specific intersection, the domain could ONLY specify intersection rules for assertion parameters.

To answer your specific question:

>can a domain define domain-specific processing that
>could state that empty nested policy IS compatible
>with non-empty nested policy?

No. If a domain were to leverage the policy intersection in the framework, the domain could not override the rules for processing nested policy expressions.

We hope this clarifies.

Regards,

Asir S Vedamuthu
Microsoft Corporation






From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B Ferris
Sent: Wednesday, May 16, 2007 10:34 AM
To: public-ws-policy@w3.org
Subject: [NEW ISSUE] 4561 clarification of domain-specific processing


http://www.w3.org/Bugs/Public/show_bug.cgi?id=4561

Title: clarification of domain-specific processing

Description: can a domain define domain-specific processing that could state
that empty nested policy IS compatible with non-empty nested policy? If so,
then I believe the spec should indicate with a MAY.

This was discussed during the telcon on 16 May
http://www.w3.org/2007/05/16-ws-policy-irc

Proposed resolution: suggest clarification text in section 4.5 and
primer/guidelines coverage that also explains this point.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

Received on Saturday, 9 June 2007 00:17:55 UTC