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] | [List Home]

Subject: Re: [xacml] Minutes from Focus Group Meeting 29 Jan 2004

Anne Anderson wrote:
> 3. WI#13 Optional Target Elements
> This is being done for economy and readability; it would not be
> backwards compatible.  Polar is happy with the optionality of
> Subjects, Resources, Actions, [Environments] - thinks it is
> actually semantically more consistent.  Simon prefers leaving it,
> but does not object if others want it.  Polar notes that
> <Subjects></Subjects> is false.  <Subjects> is modelled as a
> disjunctive sequence - absence of any elements is an edge case.
> ACTION: put Polar's note about <Subjects></Subjects> being false.

i disagree on the readability comment. from a purely philosophical 
perspective i continue to be a proponent of the Any* nomenclature for 
the simple reason is that i believe it makes policies far *more* 
understandable to humans (no offense intended, but that rules out the 
vast majority of you on the list as a result of your in depth knowledge 
of the subject skewing your perceptions toward the 'biological syntax 
evaluation processing unit' end of the spectrum ;o).

is it verbose? is it unnecessary? yes and yes, so long as you look at it 
as a medium for evaluating real-time decisions. is that we are trying to 
develop here? i would say no. xacml is an *interchange* mechanism. as 
polar and others have pointed out on numerous occasions the use of 'all 
this tagging' is horrifically cumbersome, yet we accept that fact 
because it provides a means by which disparate approaches, technologies 
and agendas can develop a common ground for interoperability.

to the best of my knowledge, no one is actually performing evaluations 
directly against an XML document. so as i see it, unless someone can 
make the case that Any* actually creates ambiguity (i have yet to see 
such), what we are really talking about here is the desire to minimize 
the conversion of a standard interchange format to internal processing 
constructs at the expense of [human] clarity. that is a mistake in my 


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