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

I support this language, but I agree that this calls for a high-level example in this section illustrating how duplicate assertions are addressed. The cases where assertion parameters have different semantics are interesting enough that such an example is needed to clarify them.

As such, +1 with an amendment to include an example to illustrate the handling of duplicates.
--
charlton_b@mac.com
+1.650.222.6507 m
+1.415.692.5396 v
 
On Saturday, June 09, 2007, at 01:18AM, "Asir Vedamuthu" <asirveda@microsoft.com> wrote:
>
>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 Wednesday, 13 June 2007 15:50:31 UTC