OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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...


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: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...

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC