[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] URI-match function proposal
working out a profile is fine with me (i was mentally preparing for it anyway ;o) as preparatory material for the profile i offer the following... true, with regex you can build all sorts of expressions that may match a variety of strings, however i would offer that any expression matching language will meet the same factors ("LIKE" being a good example). sure, one with less range in expression may be limited in its applied matches, but one that is less documented (as anything we come up with will surely be) will suffer from ambiguity. for instance, does "*" mean "zero or more"? "zero more of the char to left"? "everything to the right of a '\' (or '/')"? "everything to the right of a '\' (or '/') until you reach another '\' (or '/')"? things like only 1 wildcard per expression are appealing until you want to have something that will match this: http://foo.com/user102/bar.html http://foo.com/user102/blah.html http://foo.com/user102/oink.xml http://foo.com/user103/bar.html http://foo.com/user103/blah.html http://foo.com/user103/oink.xml is it unrealistic to want to match a variable dir (in this case user), file name and file type? if so i count 3 wildcards to match the above *accurately*. i can write a regex expression that will: * only match user dirs (user102 and user103 only or any user if desired) * match files named bar, blah or oink * match files that are suffixed html or xml ...etc. i am concerned how are we going to do something like that with "*"? the reason why regex is 'ugly' is because it spends 90% of its expressiveness *scoping* 'wildcards'. anyway, we can spiral off into the weeds of string matching later. it seems that we are agreed that v2 will go out ala reg in subtree match. (hip ){2}ho{2}ray\!$ ;o) b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]