[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: www.example.com/* 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: *.cgi 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: http://www.oreilly.com/catalog/oracleregex/ 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) myself: ^[hH][tT][tT][pP]:\/\/[eE][xX][aA][mM][pP][lL][eE]\.[cC][oO][mM]\/.*\.cgi ;o) b To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p hp.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]