[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] wd-19 indeterminate policy target handling
Hi Ray/TC, I want to emphasize that I consider this a serious issue, and hope that people can bear with what some might consider a waste of time picking at details of marginal relevance to specification. In particular, to emphasize the seriousness, please consider the following points:
and has provided detail in prev email as to the nature of that impl, as valuable input for analyzing the integrity of the algorithm that we are discussing, which is lines 5740-5799 of section C.2 of WD19, which is declared on line 5739 to "represent the normative specification of this combining algorithm". All that being said, there are a few points that Ray mentioned that I would like to respond to in the interests of advancing this discussion toward some kind of closure where we are all satisfied that the spec is meeting our objectives (which, while unstated, I assume are well understood in conventional software engineering terms). To the specific points:
that the Decision[] decisions input represents the set of values from the child nodes of the current node, and that either the decisions independently obtained from those nodes for "static" processing , or the unprocessed nodes themselves may be passed in for "dynamic" processing. If we can reach agreement on that then I think there are a couple of other minor details that we should address:
Rich On 5/21/2011 5:57 AM, remon.sinnema@emc.com wrote: 2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">Rich, From: rich levinson [mailto:rich.levinson@oracle.com] Sent: Saturday, May 21, 2011 12:06 AM To: Sinnema, Remon Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] wd-19 indeterminate policy target handlingThat being said, maybe we can rephrase the issue as to what it means when it says on line 5739: "The following pseudo-code represents the normative specification of this combining algorithm." The first line of the algorithm that follows appears to be some kind of interface signature: Decision denyOverridesCombiningAlgorithm(Decision[] decisions) << 2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">Yes, but remember this is *pseudo*-code, not actual code. IMHO, the implementation doesn't necessarily need to have the exact same interface, as long as it's conceptually equivalent, IOW, as long as it gives the same results. I think this is what Erik has been saying all along.It sounds to me like what you are saying is that when a software development organization sees that in the specification, that said organization will be completely comfortable by implementing the parameter, Decision[] decisions, by passing in an Iterator to a collection of Decision objects that have not yet been resolved. << 2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">Yes, because arrays and iterators are conceptually equivalent in this case, since the random access part of an array (that an iterator doesn't have) isn't needed for implementing any of the combining algorithms.In other words, if a development organization first implements this algorithm by passing in a precalculated array as represented by the normative interface signature, and then they complain that it is too inefficient, that I can tell them to pass in an Iterator to a collection of unprocessed nodes and just calculate the Decision objects in the first line of the loop. For example, I could suggest that the first line of the loop look something like: Decision denyOverridesCombiningAlgorithm(Iterator decisions) ... for ... { Decision decision = evaluate(decisions.next()) where Iterator.next() returns a PolicySet, Policy, or Rule, and "evaluate()" produces the Decision. << 2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">Well, the iterator should return Decisions, not unprocessed nodes, because that's what the algorithm needs to work on. The implementation of the iterator should do the evaluation when it's next() method is called. The combining algorithms shouldn't need to know anything about evaluating PolicySets, Policies, or Rules.If that is what you are suggesting and people agree, then I am ok with that, as well, I think, assuming people really believe that this is an acceptable view of the specification. << 2B109622CFC23D4BA8349254A011FBE001497D4FAB@MX27A.corp.emc.com" type="cite">I'm interested to see if anybody has any objections to this view, since this is actually how I implemented it ;) Thanks, Ray |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]