W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

RE: FW: [Bug 4552] Should the word "collection" be changed to something more specific?

From: Snow, Skip <skip.snow@citi.com>
Date: Fri, 18 May 2007 09:15:25 -0400
Message-ID: <526F87F9F4FB3E4D8710C7F5DC00C5A1065ED48D@EXNJMB28.nam.nsroot.net>
To: "Rogers, Tony" <Tony.Rogers@ca.com>, "Asir Vedamuthu" <asirveda@microsoft.com>, "David Hull" <dmh@tibco.com>
Cc: <public-ws-policy@w3.org>
For me the obligation of producer and consumer is to insure that they
can comply with all the mandatory parts of the policy. So if in a policy
document of the other agent their exists a set of All and Exactly One's
the obligation is to understand that given their offered policy that
they can comply with the other agent's policy.
 
>From a business perspective, that is what is desired, i.e. an agent
desires that it should know that it's policy requests are being honored.
If we say that 'not understanding a phrase' is permissible, then
ignorance becomes an excuse for breaking a policy. IMHO the thought that
small devices will be left out in the cold as a problem, is not the
point. a small device should be left out in the cold if it is not
capable of being secure, or doing some other mandated behavior of it's
agent-partner's policy.
 
Skip 

  _____  

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Rogers, Tony
Sent: Thursday, May 17, 2007 10:39 PM
To: Asir Vedamuthu; David Hull
Cc: public-ws-policy@w3.org
Subject: RE: FW: [Bug 4552] Should the word "collection" be changed to
something more specific?


Maybe I'm missing something: doesn't an implementation have to determine
if two assertions are the same when doing a policy intersection? I can't
see how you can do a policy intersection WITHOUT determining if
assertions are the same.
 
I think I'd have a better understanding if someone explained the
reasoning behind wanting to put two copies in the intersection result.
And I doubt I'm the only one.
 
Tony Rogers
tony.rogers@ca.com <blocked::mailto:tony.rogers@ca.com> 
 


  _____  

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Asir Vedamuthu
Sent: Thursday, 17 May 2007 1:01
To: David Hull
Cc: public-ws-policy@w3.org
Subject: RE: FW: [Bug 4552] Should the word "collection" be changed to
something more specific?



It is unclear from this mail thread re why the framework should force
implementations to figure out if two alternatives are same and filter
them out? Any technical reasons?

 

To be super clear, the quote below is not from me :-)

 

Regards,

 

Asir S Vedamuthu

Microsoft Corporation

 

 

From: David Hull [mailto:dmh@tibco.com] 
Sent: Tuesday, May 15, 2007 8:48 PM
To: Asir Vedamuthu
Cc: public-ws-policy@w3.org
Subject: Re: FW: [Bug 4552] Should the word "collection" be changed to
something more specific?

 

Asir Vedamuthu wrote: 

	the blanket statement that "collection"
	means "unordered collection with multiple occurrences allowed"
is
	inappropriate.
	    

 
Multiple occurrences of the same alternative are okay. The framework
treats them as separate alternatives. Can't imagine the technical
reasons on why the framework should force implementations to figure out
if two alternatives are same and filter them out.
  

You're defining semantics here, not implementation.  If duplicates make
no difference, you have set semantics.  If they do, you have bag
semantics.  If an implementation wants to keep duplicates around, that's
its business.

By specifying set semantics you are saying that, e.g.,

<ExactlyOne>
  <All><Foo/></All>
</ExactlyOne>

means the same as

<ExactlyOne>
  <All><Foo/></All>
  <All><Foo/></All>
</ExactlyOne>

and therefore that no one should write code that depends on one or the
other form specifically.  Similarly, no one should depend on
distinctions between <All><Foo/><Bar/></All> and
<All><Bar/><Foo/></All>.  That doesn't force implementations to maintain
alternatives in some canonical order, it just defines part of the
contract for policy authors.

While we're on the topic, it would be good to have a specific use case
in which <All><Foo/><Foo/></All> is meant to be different from
<All><Foo/></All>.  If there aren't any, then it would be better to
replace "collection" with "set" throughout.  For example, the question
of what does "all of the assertions in both alternatives" mean goes
away; you just say "union".



 
If implementers would like to optimize their implementations the
framework does not preclude filtering multiple occurrences of the same
alternative.
 
Regards,
 
Asir S Vedamuthu
Microsoft Corporation
 
 
-----Original Message-----
From: public-ws-policy-qa-request@w3.org
[mailto:public-ws-policy-qa-request@w3.org] On Behalf Of
bugzilla@wiggum.w3.org
Sent: Friday, May 11, 2007 8:14 AM
To: public-ws-policy-qa@w3.org
Subject: [Bug 4552] Should the word "collection" be changed to something
more specific?
 
 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4552
 
 
dmh@tibco.com changed:
 
           What    |Removed                     |Added
------------------------------------------------------------------------
----
                 CC|                            |dmh@tibco.com
 
 
 
 
------- Comment #1 from dmh@tibco.com  2007-05-11 15:13 -------
My understanding from the list discussion is that policies are *sets* of
alternatives, not bags, in that it does not matter how many times an
alternative appears, so long as it appears.
 
If so, then the blanket statement that "collection" means "unordered
collection
with multiple occurrences allowed" is inappropriate.  If policies are
allowed
to contain the same alternative multiple times, then someone has to say
what
the differences is between, e.g., an alternative occurring once and the
same
alternative occurring twice.
 
Conversely, if there is no difference, then say so explicitly.  That is,
instead of saying "A policy is a collection (unordered, multiples
allowed) of
alternatives where multiplicity doesn't matter", say directly that "A
policy is
a set of alternatives".
 
  

 
Received on Friday, 18 May 2007 13:18:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:51 GMT