[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of the 17 June 2004 Focus Group
Minutes from the 17 June 2004 XACML Focus Group Attendees: Michiharu Kudo Anne Anderson Tim Moses Frank Siebenlist Simon Godik 1. Anne announced W3C Workshop on Constraints and Capabilities for Web Services to be hosted at the Oracle Conference Center at Oracle Headquarters in Redwood Shores in California. Earlier mail had suggested that this workshop would be jointly sponsored by W3C and by OASIS. Tim will check on this. Workshop dates: 12-13 October 2004 Position papers due: 27 August 2004 Final agenda: 24 September 2004 Registration closes: 1 October 2004 2. URI matching functions Summary of current discussion: Tim's original proposal borrowed from JSR115. Michiharu commented: 1) why not call it URI-match, instead of URL match, 2) Why not have two functions: one for whole subtree, and one for one node. Wildcard in one just means any sub-node. In other means direct child nodes. Bill P commented: could do it all with different wildcard conditions. Rich Salz submitted a comment this morning. Tim does not mind having two functions. Has slight reservations on having two functions where a wildcard means different things in the two functions. He is leaning toward Bill's suggestion. Polar suggested: ** means string of sub-nodes, * means just one level of sub-nodes. Bill suggested: define general match function in core, with optional like "hierarchy". Part of a regular expression matching function. Rich Salz submitted a proposal that allows interior matches. Tim modified his proposal to include "**" in response to Rich. New discussion: Michiharu described a problem with using general regular expressions. JSR 115 does not support "**". XPath does have a syntax for this: "//". Tim: names: - url-node-match: wildcard indicates one level of node match Could do this using url-node-match: file://x/y* - matches //x/y, //x/yaz, //x/yaz.txt, etc. file://x/* - matches //x/y, //x/z, //x/ya, but not //x/y/z file://x/y*.html - matches //x/y.html, //x/ya.html, etc. - url-subtree-match: wildcard indicates arbitrary number of levels file://x/y* - matches //x/y, //x/yaz, //x/yaz/a //x/yaz/a/b/c, etc. file://x/* - matches //x/y, //x/z, //x/y/a file://x/*/y*.html - matches //x/y.html, //x/a/ya.html Anne: Two types of wildcard matching - level: could use "//" - within a level: could use * Tim: Could we use regular expressions for matching the <pathname> part? "*" could occur in the middle of a string. Anne: Michiharu also wants to support relative URL matching; i.e. /a/b, without a scheme or authority Michiharu: wants to support all formats in RFC2396, including absolute path forms. /..., etc. Anne: we don't have a semantically meaningful way to support relative paths that include "." or "..", since there is nothing defined in our match functions for the "." or ".." to be relative to. Michiharu agrees. Michiharu: just wants to express a policy which is usually done in a file system where you can grant access on a directory and its descendants. Anne: let's submit use cases so we can get requirements for exactly what we need to support. [ACTION ITEM]: Tim will draft a list of requirements from the various suggestions. Others are also welcome to submit use cases. [ACTION ITEM]: If requirements seem clear, Tim will define a single function, making scheme and authority optional, and possibly using regular expression matching for the <pathname> portion. The meeting adjourned at 10:53am EDT. -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]