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] 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:


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 

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


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)


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