RE-wording for my action on "domain"

I still find the action item to be quite cryptic and not at all what I 
recall from the meeting, but then again I'm new to this whole process and 
still am a bit of a beginner in reading through the lines here......in the 
future I will type more into the IRC so that I can be sure to understand 
what these action items really are.

Many of you seem to be able to just "fill in the blanks" but I'm still a 
little confused so please bear with me.

Maryann
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


the specific text is the following:


3.4 External Policy Attachment
This mechanism allows policies to be associated with a policy subject 
independent of that subject's definition and/or representation through the 
use of a wsp:PolicyAttachment gelement.
This element has three components: the policy scope of the attachment, the 
policy expressions being bound, and optional security information. The 
policy scope of the attachment is defined using one or more extensible 
domain expressions that identify policy subjects, typically using URIs.
Domain expressions identify the domain of the association. That is, the 
set of policy subjects that will be considered for inclusion in the scope 
using an extensible domain expression model. Domain expressions identify 
policy subjects to be included within the policy scope. Domain expressions 
yield an unordered set of policy subjects for consideration. 


There is no defintion of "domain" in either of our specifications and we 
use the term ambiguously in both  the Framework document, in the context 
of defining assertions and in the Attachments document in the context of 
scoping assertions to a particular set of policy subjects.

I believe the issue is larger than just addressing this paragraph, however 
this was not captured in the specific meeting text ......Asir I'm amazed 
you can make any sense out of it......but obviously you think its just a 
simple change.

So, 
here are several alternatives for the editors to consider:

1)  only fix the paragraph and remove the "offending" use of the term 
"domain".

3.4 External Policy Attachment
This mechanism allows policies to be associated with a policy subject 
independent of that subject's definition and/or representation through the 
use of a wsp:PolicyAttachment element.
This element has three components: the policy scope of the attachment, the 
policy expressions being bound, and optional security information. The 
policy scope of the attachment is defined using one or more extensible 
domain expressions that identify policy subjects, typically using URIs.
Domain expressions identify the domain of the association. That is, t When 
using this type of attachment, the set of policy subjects that will be 
considered for inclusion in the scope using an extensible domain 
expression model will be defined by the community using the attachment 
model. Domain expressions identify policy subjects to be included within 
the policy scope. Domain  When multiple expressions are present, the 
expressions they yield an unordered set of policy subjects for 
consideration. 

In the example below we provide an illustration of this attachment model 
using a WS-Addressing  endpoint as a policy subject.

<wsp:PolicyAttachment>
  <wsp:AppliesTo>
    <wsa:EndpointReference>
      <wsa:Address>http://www.example.com/acct</wsa:Address>
    </wsa:EndpointReference>
  </wsp:AppliesTo>
  <wsp:PolicyReference
     URI="http://www.example.com/policies#RmPolicy" />
</wsp:PolicyAttachment>


2) 
2a) include in our definitions ( probably in the Framework document ) some 
definitions and then make the appropriate clarifications ( 2b, 2c, and 
there may be others.....I thought it might be good to start with an 
example of how to qualify our use, and then to go through the documents 
and make sure that all use of the term was either intended to be the 
"generic" use of  "domain" or a qualified use specific to this 
specification) 

This item may overlap with the new action item Toufic took today.


Domain - The term is very overloaded and the original etymological 
implication of the word domain carries the idea of "something ruled". For 
the purposes of this specification we define qualified terms for our use 
wherever possible within the policy framework and policy attachment.

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. 

2b)
change section 3.4 

3.4 External Policy Attachment

This mechanism allows policies to be associated with a policy subject 
independent of that subject's definition and/or representation through the 
use of a wsp:PolicyAttachment element.
This element has three components: the policy scope of the attachment, the 
policy expressions being bound, and optional security information. The 
policy scope of the attachment is defined using one or more extensible 
domain expressions that identify policy subjects, typically using URIs.
Domain expressions identify the domain of the association. That is, t When 
using this type of attachment, WS-Policy domain authors must define  the 
set of policy subjects that will be considered for inclusion in the scope 
using an extensible domain expression model . Domain expressions identify 
policy subjects to be included within the policy scope. It is recommended 
that WS-Policy domain authors consider that  multiple WS-Policy Domain 
expressions can yield an unordered set of policy subjects for 
consideration when designing their domain assertions. 


2c) make the text is policy framework also incorporate the definitions in 
2a)

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 WS-Policy domain-
specific, Web Service policy information. 
A core set of constructs to indicate how choices and/or combinations of 
WS-Policy domain-specific policy assertions apply in a Web services 
environment.
.... 
3.1 Policy Assertion 
A policy assertion identifies a behavior that is a requirement (or 
capability) of a 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 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. 
WS-Policy Domain authors MAY define that an assertion contains a 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 define
d 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 and 
want to limit the policy alternatives 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 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). 
... 
Assertion parameters 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