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

Tim Moses wrote:
> Colleagues - Attached is my first attempt to describe the use-case for a
> simple URL matching function.  Let me know what you think.  This is not an
> attempt to write a "flexible string matching language".  But, perhaps it can
> coexist with the regular expression approach that Bill has described and
> that may be required to address more general requirements.  All the best.
> Tim.

sorry, but i continue to have a concern where we are attempting to 
create our own matching language. in the posted example where we have:


the assumption is made that "*" represents all characters. this is not a 
"subset" of regex ("*" propagates the char to its immediate left). it 
seems to be based upon the use of "*" for file systems, but neither 
windows nor unix allow propagation (subdirectory) matching--there is an 
implicit mapping to a file system structure with url strings that i 
believe will introduce confusion. prior postings attempt to correct this 
by introducing "**" (a component of ant).

compounding the problem is the addition of this:


which seems simple until you decide that you want *.cgi and/or *.pl in 
the match. this would require some sort of string combiner mechanism to 
deal with i am guessing. while the argument against regex is too 
expressive--and therefore can generate unintended results--that is 
precisely what i am trying to avoid by creating our own language.

in general, i am trying to avoid recreating this:


but more specifically, prevent having an ambiguous representation in the 
process of doing so. the proposed url-matching function requires 3 more 
chars to provide the same (intended) match: "http://www.example.com"; and 
"\/.*\.cgi". on the other hand, it provides a concise and well 
documented model for matching strings.

of course, with all that said, i would just use this (via regex match) 




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