xacml — archive

RE: [xacml] condition reference text (item 7)

From: Anne Anderson <[email protected]>
To: [email protected]
Date: Fri, 12 Mar 2004 14:42:00 -0000

 MHonArc v2.5.0b2 -->

xacml message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: RE: [xacml] condition reference text (item 7)

From: Anne Anderson <[email protected]>
To: Tim Moses <[email protected]>
Date: Fri, 12 Mar 2004 09:56:23 -0500

On 12 March, Tim Moses writes: RE: [xacml] condition reference text (item 7)
 > Colleagues - I have just realized how much work this is going to be.  In
 > addition to the specific changes described by Simon, all the examples are
 > affected and the introductory material, including the class diagram are
 > affected.  This is going to take some time.
 >  
 > I would like to see formal acceptance of the proposal as soon as possible,
 > because backtracking doesn't look like an appealing option.
 >  
 > Personally, I lament the passing of <Condition>.  The part of <Rule> that
 > complements <Target> is a significant independent concept that deserves its
 > own name.  Anyone who has to explain XACML will have to refer to it.  With
 > the passing of <Condition>, they'll have to talk about "the child
 > <Expression> element of the <Rule> element" or some such.  Global replace
 > may work for the editor, but it is not a very attractive prospect for the
 > reader.
 >  
 > Does anyone else feel that this idea needs a name of its own?

Yes, I do.  The type of the Condition element can be shared with
the other expressions, but giving the element that contains the
set of predicates for a Rule its own name is a minor addition
with major readability benefits.

The counter argument might be that people won't read XACML
policies, and the tools that generate them don't care what the
name is.  As someone who frequently presents and explains XACML
to customers and partners, I can attest that being able to
present readable, short examples is essential to obtaining
broader acceptance for XACML.  We will not have many tools until
enough human readers have decided XACML is a good language.

Anne

 > All the best.  Tim.
 > 
 >