Title: 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:]
Sent: Monday, April
15, 2002 2:38 PM
To: ''
Subject:
[xacml] E-mail vote results, and one outstanding
question...
Hello,
Here are the results of
the e-mail vote that took place last week.
I counted votes from 9
members (Polar, Bill, Don, Hal, Ken, Konstantin, Pierangela, Michiharu, and
Anne); this is quorum.
BATCH #1: all nine
voted to accept these resolutions without amendment, with the exception that
Konstantin abstained on PM-2-01. These resolutions are therefore
approved and the issues are officially closed.
BATCH #2: all nine
voted to accept the resolutions to PM-2-06 and PM-8-05 without
amendment. These resolutions are therefore approved and the issues are
officially closed. The other issues in batch #2 have the following
status:
-
PM-2-05: seven voted to approve the resolution with Konstantin's
amendment. Hal and Ken officially voted to approve the
originally-proposed resolution. Since the amendment is to clarify the
purpose of "will list the names" (making it "MAY list the names" instead), and
since Hal has stated in a separate e-mail to the list that he has no objection
to "the MAY language" for this, I declare this resolution with Konstantin's
amendment approved, and the issue officially closed.
-
MI-1-03: five voted to approve the resolution as originally stated; four
voted to approve Hal's amendment. Again, the amendment is to change the
wording so as to clarify the intent of the resolution. Anne (who wrote
the original resolution) stated in an e-mail to the list about Hal's
amendment, "I accept your amendment: it more
clearly expresses what I had in mind and what I think the TC decided on." Unless I hear an objection
by tomorrow, I declare this resolution with Hal's amendment approved, and the
issue officially closed.
-
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.
