RE: Action164

Folks, 
 
I had some discussion offline about this action item with Asir. Although
the writeup below reflects the discussion we had at that time, I agree
with him that the resulting recommendation has a flaw. There are two
problems that pertain to Issue 3979. 
 
(1) Parameters in an assertion that are static as we exemplified and
they may be reused. However, they can not benefit necessarily from
xml:id/name attribute because they are not assertions themselves as we
seem to imply with the writeup in this thread. A different inclusion
approach would be appropriate, such as XInclude. Thus, the example that
we use from WS-Security does not fit with the policy expression naming
mechanism. 
 
(2) The guidance on promoting reuse, etc. applies to more to policy
expression authors, than policy assertion authors. 
(a) The guidance on promoting reuse and manageability are general
concepts that affect primarily policy expressions authors. 
(b) The attachment of policy subjects via referencing may be beneficial
both policy expression and assertion authors. 
 
Personally, I am not as particular in dividing the two documents target
users very strickly and I am not too concerned that our primer is for
policy expression authors and the guidelines are only for authors that
develop assertions only. In my personal experience and given the makeup
of even our group, these target audiences do overlap and we have
provision in the guideline document's Introduction  to indicate that. 
 
However, for the sake of making progress, here is what I can offer as
another proposal for closing 3979. I offer two sets of changes, one for
the primer and one for the guidelines. Have a look
 
In primer, include the following paragraph in Section 2.9 at the end. 
 
{ As policy expressions are composed from other policy expressions and
assertions from different domains are used in a policy expression,
complex expressions will emerge. Naming parts of complex expressions for
reuse and building more complex policies through referencing enables
building more complicated policy scenerios easily. This approach enables
the association of additional policy subjects to identified policy
expressions.  It also promotes manageability of the expressions as they
are uniquely identified and allows profiles for common scenerios to be
developed. Note that when a named expression has assertions that
contains parametrized expressions, care must be given to ensure that the
parameterized content is statically available to enable reuse.}
 
In the guidelines, replace the paragraph in question (which is the
entire Section 5.2) with the following paragraph
 
{The Web Services Policy Primer illustrates how providers can utilize
the identification mechanism defined in the Policy specification to
expose a complex policy expression as a reusable building block for
other policy expressions by reference. Reuse may also be useful for
domain assertion authors, especially those defining complex assertions
utilizing references to policy expressions by nesting. Statically
available parameterized content may also be reused by different
assertions. However, such referencing mechanism is outside the scope of
WS-Policy naming and referencing framework and other mechanisms, such as
XInclude, could be used. As an example, in Web Services Policy Primer
Section 4.2, the sp:issued Token assertion utilizes the
sp:RequestSecurityTokenTemplate parameter that contains necessary
information to request a security token. The contents of the parameter
are static and allows reuse in different security scenerios. }


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
	Sent: Tuesday, Dec 19, 2006 6:06 PM
	To: public-ws-policy@w3.org
	Subject: Action164 
	
	

	I have taken an action item [Action 164] to reword the following
text as part of [Issue 3979]. This is to capture the results of the
discussion as part of the Guidelines Document from the Meeting Minutes.
This completes my action item. 

	The offending text: (particularly the term "naming convention").
The paragraph is repeated to give context.  Note that this section no
longer corresponds to Section 5.9.1. but Section 5.1. I have reworded
the sentence to remove "naming convention" and added text capturing the
discussion. 

	Have a look. 

	--umit 


	Old text: 

	{The Web Services Policy Primer illustrates how providers can
utilize the identification mechanism defined in the Policy specification
to expose a complex policy expression as a reusable building block for
other policy expressions by reference. Domain assertion authors,
especially those defining complex assertions that include nesting or
complex types should consider specifying or recommending naming
conventions in order to promote reuse. Reuse through referencing allows
a policy expression to be utilized not only within another expression
but also allows specification of additional policy subjects and their
association to common policy expressions that are identified. It also
promotes manageability of the expressions as they are uniquely
identified. }

	Replace by: 
	{The Web Services Policy Primer illustrates how providers can
utilize the identification mechanism defined in the Policy specification
to expose a complex policy expression as a reusable building block for
other policy expressions by reference. Domain assertion authors,
especially those defining complex assertions using nesting or
parameterized assertions, may consider using identification mechanisms
when the nested or parameterized content could be utilized in different
contexts and/or serve as a template for later reuse. Reuse through
referencing allows a policy expression to be utilized not only within
another expression but also allows specification of additional policy
subjects and their association to common policy expressions that are
identified. It also promotes manageability of the expressions as they
are uniquely identified. When assertions contain parametrized
expressions and reuse is desired, care must be given to ensure that the
parameterized content is statically available. As an example, in Web
Services Policy Primer Section 4.2, the sp:issued Token assertion
utilizes the sp:RequestSecurityTokenTemplate parameter that contains
necessary information to request a security token. The contents of the
parameter are static and allows reuse in different security scenerios. }



	[Issue 3979] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979>  

	[Action 164]
http://www.w3.org/2006/12/06-ws-policy-minutes.html#action06
<http://www.w3.org/2006/12/06-ws-policy-minutes.html#action06>  


	---------------------- 

	Dr. Umit Yalcinalp 
	Architect 
	NetWeaver Industry Standards 
	SAP Labs, LLC 
	Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
	SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
<https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238>  
	-------- 
	"Nearly all men can stand adversity, but if you want to test a
man's character, give him power." Abraham Lincoln.