RE: NEW ISSUE: Require assertions to be distinguished from parameter elements

Hi Frederick,

> A generic policy processor cannot distinguish 
> from an XML element by itself whether it is 
> an assertion or a parameter

Let us look at the distinction at the XML representation level:

Policy Assertion - A child element of the Policy, All or ExactlyOne
element that is not from the WS-Policy XML namespace is a policy
assertion.

Policy Assertion Parameter - A child element or an attribute of a policy
assertion element that is not from the WS-Policy XML namespace is a
policy assertion parameter.

Given these, the distinction between an assertion and a parameter is
unambiguous for machines that read a policy expression.

There are test cases that use assertions and assertion parameters in the
contributed interop scenarios pack [1]. Several implementers ran these
test cases. I am not aware of any related interop issues.

[1]
http://lists.w3.org/Archives/Public/public-ws-policy/2006Jun/0010.html

> normalization algorithm needs to 
> explicitly account for passing  
> through parameter elements.

Policy assertion parameters are the opaque content (or payload) of an
assertion. Parameters carry additional useful information for engaging
the behavior described by an assertion and are preserved through policy
processing such as normalize and merge. For normalization, I am not
aware of a need for passing through parameter elements.

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 Frederick Hirsch
Sent: Wednesday, July 12, 2006 5:14 AM
To: public-ws-policy@w3.org
Cc: Frederick Hirsch
Subject: NEW ISSUE: Require assertions to be distinguished from
parameter elements


Title - Require assertions to be distinguished from parameter elements

Description - A generic policy processor cannot distinguish from an  
XML element by itself whether it is an assertion or a parameter, yet  
they are treated differently in intersection operations. For this  
reason the Framework specification must distinguish the two.

Justification -

A generic policy processor should be able to perform generic  
intersection operations on policy without knowledge of every possible  
policy domain. This allows extensibility. In addition, the  
normalization algorithm needs to explicitly account for passing  
through parameter elements.

Target - WS-Policy Framework [1]

Proposal - add requirement statement to Framework document, and  
update examples correspondingly: "Every assertion must be the direct  
child of a wsp:Policy element, and every parameter element must not  
be a direct child of a wsp:Policy element."

Change step 3.2 of 4.2 normalization procedure to be:
"2. If the Element Information Item C is a child of a Policy element;  
normalize C per Sections 4.3.1 Optional Policy Assertions and 4.3.2  
Policy Assertion Nesting. Otherwise, copy Element C to the output."

Test1:

The following two assertions should match:

<wsp:Policy
   xmlns:ex="http://www.example.com/example"
   xmlns:foo="http://www.example.com/parameter"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" >
	<ex:Example >
	  <foo:Something />
	</ex:Example>
</wsp:Policy>


<wsp:Policy
   xmlns:ex="http://www.example.com/example"
   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" >
	<ex:Example >
	</ex:Example>
</wsp:Policy>


Test2:

If it is known that foo:Something is an assertion, then a processor  
that is able to perform validity checking should flag an error. This  
may require an implementation that accepts a list of known assertions  
as an input for validity checking.


regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/Submission/WS-Policy/

Received on Monday, 24 July 2006 03:13:36 UTC