[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 opinion. b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]