Re: [xacml] URI-match function proposal

[Bill Parducci <bparducci@gluecode.com>]

Michiharu Kudoh wrote:
> I should have written that I am not trying to create yet another regular
> expression match. I just tried to create a simple but useful convention for
> hierarchy-wise matching.
> Since we are extending XACML to support hierarchical resource, I think
> XACML needs to show a right-focused hierarchical match solution that works
> on hierarchical string representation (URI syntax). Some of them have been
> summarized in the hierarchical resource profile document and this would be
> one new addition to the profile (it means OPTIONAL)

and i would offer that more will continue to show up as we encounter 
numerous examples that have not be covered by our attempt at writing a 
flexible string matching language.

> Conventional regular expression standard could support our needs but the
> reg-exp examples somehow loses policy writer's intuition on hierarchy-wise
> matching (I am saying that policy writer could not write that syntax). If
> hierarchy-wise matching expression could be converted into reg-exp
> expression, it helps implementer. They don't have to implement their own
> code for the hierarchy-wise matching. I think we should focus on the issue
> of what is the right-focused hierarchy-wise matching solution to XACML
> users, not only from implementers' perspective.

ultimately i agree, but i consider our first requirement to be 
deterministic policy interchange and i fear that the impreciseness of 
our matching semantics will impede that because we do not have something 
we can point to and say, 'that is a hierarchy' (as is the case with 
simple URIs, email addresses, etc.) via external reference and apply 
some implementation tweaks.

> Re the syntax, I have no problem with removing '?' letter from my proposal.
> Hierarchy-wise matching works only at the relativeURI portion of the URI
> syntax and is supported only using "*", "**", and "***". "*" and "**" are
> borrowed from Apache ANT. Only "***" is my artifact but it is just a
> technical syntax sugar and useful for representing a policy in concise
> manner.

personally, i think the functionality of the '?' adds value and that is 
my point. there are many such mechanisms that have demonstrable value 
for making the corpus of policies more concise, my problem lies in our 
attempting to create the expressions for such.

again, regex can be ugly and counterintuitive, but it IS precise and it 
can be tested very easily. i also have problems with the argument that 
regex impedes policy writers given that we expect XPath expressions to 
be used all over the place (i don't know too many non-IS types who can 
gen those reliably ;o)

just my two cents. i was on board with 'simple extensions' originally 
but the discussion has changed my mind; i don't think the extensions 
will stay simple.

b