RE: proposed text for AI #15

I must admit I've always found the use of the word "domain" in these
specs confusing.  That's probably because I've been a bit late to the
game on this.  In general, I'm not sure why the word Domain is even
used, and defined instead of just "assertion".  
 
For example, the 2nd paragraph of the proposed 3.1 says
WS-Policy Domain authors MAY define that an assertion contains a policy
expression
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_expression>  as one
of its [children]. Policy expression nesting is used by WS-Policy domain
authors to further qualify one or more specific aspects of the original
assertion. For example, security domain authors may defined an WS-Policy
assertion describing a set of security algorithms to qualify the
specific behavior of a security binding assertion. 

Why not say instead:
WS-Policy Assertion authors MAY define that an assertion contains a
policy expression
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_expression>  as one
of its [children]. Policy expression nesting is used by WS-Policy
assertion authors to further qualify one or more specific aspects of the
original assertion. For example, security assertion authors may defined
an WS-Policy assertion describing a set of security algorithms to
qualify the specific behavior of a security binding assertion. 
 
?
 
What I'd like to see is a clear case of where something is
"domain-specific" and not "assertion-specific", and vice-versa.  
 
Now, assuming that I'm out to lunch on this, that there is a real need
for domain to be detailed as shown, I'd like to see the definitions
inlined as we've done with all the other definitions.
 
Cheers,
Dave

 
 



________________________________

	From: public-ws-policy-eds-request@w3.org
[mailto:public-ws-policy-eds-request@w3.org] On Behalf Of Maryann Hondo
	Sent: Wednesday, August 02, 2006 11:23 AM
	To: public-ws-policy-eds@w3.org
	Subject: proposed text for AI #15 
	
	

	As per my actions:
http://www.w3.org/2006/07/27-ws-policy-minutes.html
<http://www.w3.org/2006/07/27-ws-policy-minutes.html> : 
	<scribe> ACTION: editors to clear up 3.4 paragraphs about domain
and also define domain expression [recorded in
http://www.w3.org/2006/07/13-ws-policy-minutes.html#action15
<http://www.w3.org/2006/07/13-ws-policy-minutes.html#action15> ] 
	
	Although the Action Items refers to text in section 3.4 there is
no specific reference to "domain" in this section. 
	Here is the list of my suggested changes for "domain" 
	
	Maryann 
	
	
----------------------------------------------------------------------- 
	
	Proposed new definitions: 
	
	
-----------------------------------------------------------------------
	Domain - The original etymological implication of the word
domain carries the idea of "something ruled". In Information Technology
it commonly refers to a machine or a host on the Internet.(
http://en.wikipedia.org/wiki/Domain) 
	
	A "WS-Policy Domain" is a logical grouping  of assertions that a
particular community has agreed to define (in conformance with the
WS-Policy specifications) to facilitate the interoperability of web
services within that community of interest. 
	
	A "WS-Policy domain expression" is an XML representation of a
capability or a constraint within the context of a WS-Policy domain or
community of interest. 
	
	
----------------------------------------------------------------------- 
	
	Proposed edits ( in bold and strikethrough) 
	
	
-----------------------------------------------------------------------
	1.1 Goals 
	The goal of Web Services Policy 1.5 - Framework is to provide
the mechanisms needed to enable Web services applications to specify
policy information. Specifically, this specification defines the
following: 

	*	An XML Infoset called a policy expression that contains
domain-specific, Web Service policy information. 
	*	A core set of constructs to indicate how choices and/or
combinations of domain-specific policy assertions apply in a Web
services environment.

	.... 
	3.1 Policy Assertion 
	A policy assertion
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_assertion>
identifies a behavior that is a requirement (or capability) of a policy
subject
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_subject> .
Assertions indicate WS-Policy domain-specific (e.g., security,
transactions) semantics and are expected to be defined in separate,
WS-Policy domain-specific specifications [i.e. WS-SecurityPolicy,
WS-ReliableMessagingPolicy] .Assertions are strongly typed by the domain
authors that define them. The policy assertion type
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_assertion_type>  is
identified only by the XML Infoset [namespace name] and [local name]
properties (that is, the qualified name or QName) of the root Element
Information Item representing the assertion. Assertions of a given type
MUST be consistently interpreted independent of their policy subjects
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_subject> . 
	WS-Policy Domain authors MAY define that an assertion contains a
policy expression
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_expression>  as one
of its [children]. Policy expression nesting is used by WS-Policy domain
authors to further qualify one or more specific aspects of the original
assertion. For example, security domain authors may defined an WS-Policy
assertion describing a set of security algorithms to qualify the
specific behavior of a security binding assertion. 
	The XML Infoset of an assertion MAY contain a non-empty
[attributes] property and/or a non-empty [children] property. Such
content MAY be used to parameterize the behavior indicated by the
assertion. For example, an assertion identifying support for a specific
reliable messaging mechanism might include an attribute information item
to indicate how long an endpoint will wait before sending an
acknowledgement. 
	WS-Policy Domain authors should be cognizant of the processing
requirements when defining complex assertions containing additional
assertion content or nested policy expressions. Specifically, WS-Policy
domain authors are encouraged to consider when the identity of the root
Element Information Item alone is enough to convey the 
	
	4.4 Policy Intersection 
	Policy intersection is useful when two or more parties express
policy
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy>  and want to limit
the policy alternatives
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_alternative>  to
those that are mutually compatible. For example, when a requester and a
provider express requirements on a message exchange, intersection
identifies compatible policy alternatives (if any) included in both
requester and provider policies. Intersection is a commutative,
associative function that takes two policies and returns a policy. 
	... 
	Because the set of behaviors indicated by a policy alternative
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_alternative>
depends on the domain-specific semantics of the collected assertions,
determining whether two policy alternatives are compatible generally
involves WS-Policy domain-specific processing. As a first approximation,
an algorithm is defined herein that approximates compatibility in a
WS-Policy domain-independent manner; specifically, for two policy
alternatives to be compatible, they must at least have the same
vocabulary (see Section 3.2 Policy Alternative
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#rPolicy_Alternative> ). 
	... 
	Assertion parameters
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.
html?content-type=text/html;%20charset=utf-8#policy_assertion_parameter>
are not part of the compatibility determination defined herein but may
be part of other, domain-specific compatibility processing. 
	... 
	As this example illustrates, compatibility between two policy
assertions is based on assertion type and delegates parameter processing
to domain-specific processing. 
	... 
	Note that there are > 1 assertions of the type sp:SignedParts ;
when the behavior associated with sp:SignedParts is invoked, the
contents of both assertions are used to indicate the correct behavior.
Whether these two assertions are compatible depends on the
domain-specific semantics of the sp:SignedParts assertion. To leverage
intersection, assertion authors are encouraged to factor assertions such
that two assertions of the same assertion type are always (or at least
typically) compatible.