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

Bill - Are you (furthermore) claiming that your proposal addresses my
use-case (i.e. locating and retrieving applicable policies from an SQL
database)?  If so, I would like to understand how.  All the best.  Tim.

-----Original Message-----
From: Bill Parducci [mailto:bparducci@gluecode.com] 
Sent: Friday, July 09, 2004 9:59 AM
To: 'xacml'
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) 




To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to

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