[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] E-mail vote results, and one outstanding question...
Hi Konstantin,
Yes, this definitely helps.
However, if we need to point to a section in the OCL spec in order to explain what is meant by certain operators, then I'm more convinced than ever that the pseudocode currently in Section 7.1 is preferable. That pseudocode seems crystal clear to me (without having to read any further explanations!) and its semantics should be immediately clear to any software implementer, which is the ultimate intent.
Am I the only one feeling hesitant about using OCL for our combiner algorithms? Did everyone else in the group look at the OCL example and know instantly what code they would have to write to implement that combiner?
Carlisle.
----------
From: Beznosov, Konstantin[SMTP:Konstantin.Beznosov@Quadrasis.com]
Sent: Monday, April 15, 2002 4:12 PM
To: Carlisle Adams; xacml@lists.oasis-open.org
Subject: RE: [xacml] E-mail vote results, and one outstanding question...
Carlisle,
To help clarifying one of the questions from your message, here's a section from OCL spec on "exists" operation on collections:
------------------------------------------------------------------------------------
Many times one needs to know whether there is at least one element in a collection for which a constraint holds. The exists operation in OCL allows you to specify a Boolean expression that must hold for at least one object in a collection:
collection->exists( v : Type | boolean-expression-with-v )
collection->exists( v | boolean-expression-with-v )
collection->exists( boolean-expression )
This exists operation results in a Boolean. The result is true if the boolean-expression-with-v is true for at least one element of collection. If the boolean-expression-with-v is false for all v in collection, then the complete expression evaluates to false. For example, in the context of a company:
context Company inv:
self.employee->exists( forename = 'Jack' )
context Company inv:
self.employee->exists( p | p.forename = 'Jack' )
context Company inv:
self.employee->exists( p : Person | p.forename = 'Jack' )
These expressions evaluate to true if the forename feature of at least one employee is equal to 'Jack.'
-------------------------------------------------------------------------------------------
Hope this helps.
Konstantin
-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Monday, April 15, 2002 2:38 PM
To: 'xacml@lists.oasis-open.org'
Subject: [xacml] E-mail vote results, and one outstanding question...
- PM-3-04: six voted to approve OCL as the language to express combiner algorithms; Hal and Ken voted to accept the originally-proposed resolution (i.e., Java); Anne voted for Java or, failing that, C/C++ (but would be happy to accept OCL "if that is what the majority wish"). My personal objection to OCL is that the example that Konstantin posted did not seem as clear to me as the pseudocode example (in particular, I found the operator "exists" to be entirely non-intuitive), so I wonder how many readers/implementers of XACML will struggle with this. I am willing to close this issue since the majority has voted in favour of OCL, but I would prefer to continue discussions on this issue until Thursday's TC call. Remember that the only goal is to be able to specify as clearly as possible what we want the combiner to do. On a first glance, OCL doesn't do that for me. I don't think we need to have a real software language for this, although that might be nice. I don't even think we necessarily have to have a standardized pseudocode; anything will do, as long as it is clear. For the small number of combiner algorithms that we will include in XACML 1.0, what we currently have in v0.12 seems fine to me. Can someone explain why OCL is a better choice than the current Section 7.1 if all we want to do is say what we mean by "deny overrides"?
Carlisle.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC