[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Summary of the discussion on Function model
This is a summary of the discussion among Daniel, Polar and me. I could not list all the issues we discussed. Daniel and Polar: please correct me if I misunderstood. ============================================ A. Changes of the latest function draft v0.9 from v0.8 - Higher-order sequence function is added B. Problems of the previous function draft v0.8) - Sequence but unordered set - The semantics of function:string-equal in MatchId corresponds to the semantics of function:string-member-of - Comparison on multiple data (sequence or set) is limited to string data type C. Three ideas on comparison on sequences Daniel: Sequence handled by each function Polar: Sequence handled by higher-order function Michiharu: Sequence is handled in a way used by XPath 2.0 data model D. Issues of draft v0.8 0042: In ver 0.8, string comparison (set against a value) is differently specified in MatchId from in Apply 0043: Should we support ordered set (sequence) type or unordered set? 0044: Should we distinguish sequence of data from singleton data? 0045: Should we support higher-order function? 0046: Should we support basic sequence comparison model? E. Position ==== 0042: In ver 0.8, string comparison (set against a value) is differently specified in MatchId from Apply Attribute selector returns a sequence (e.g. "aaa" and "bbb"). In ResourceMatch, function:string-equal is used <ResourceMatch MatchId="function:string-equal"> <AttributeSelector RequestContextPath="/a/b/c/text()"> <AttributeValue>bbb</AttributeValue> </ResourceMatch> In Apply, function:string-member-of is used <Apply FunctionId="function:string-member-of"> <AttributeValue>bbb</AttributeValue> <AttributeSelector RequestContextPath="/a/b/c/text()"> </Apply> ver0.9: - ??? Daniel: - ??? Polar: - Higher-order function introduced in ver 0.9 will resolve this inconsistency. ??? for <ResourceMatch> <Apply FunctionId="function:any-of-each"> <Function FunctionId="function:string-equal"/> <AttributeDesignator AttributeId="role1"/> <AttributeValue>bbb</AttributeValue> </Apply> Michiharu: - Comparison model on sequence data will resolve this inconsistency. <ResourceMatch MatchId="function:string-equal"> <AttributeDesignator AttributeId="role1"/> <AttributeValue>bbb</AttributeValue> </ResourceMatch> <Apply FunctionId="function:string-equal" ComparisonBase="Each"> <AttributeDesignator AttributeId="role1"/> <AttributeValue>bbb</AttributeValue> </Apply> ==== 0043: Should we support ordered set (sequence) type or unordered set? ver0.9: - Sequence is supported but it is unordered (?) - Some value may be repeated Daniel: - unordered set because it is a subset of ordered set - small coverage is good for initial mandatory data model Polar: - sequence Michiharu: -sequence because it is a superset of unordered set -unordered set is supported as a subset of ordered set -XML document (XACML Request Context) supports sequence -application that uses unordered set of data is also supported using function that is not sensitive on sequence. ==== 0044: Should we distinguish sequence of data from singleton data? ver 0.9: - ??? Daniel: - Singleton data should be handled as a sequence which length is one. Polar: - Singleton data should be distinguished from singleton data Michiharu: - Singleton data should be handled as a sequence which length is one. ==== 0045: Should we support higher-order function? ver 0.9: - Supported Daniel: - Should not be supported Polar: - Can be supported if the idea of comparison base is introduced Michiharu: - Generic higher-order function is not necessary - XPath 2.0-based comparison should be supported (http://lists.oasis-open.org/archives/xacml/200209/msg00071.html) ==== 0046: Should we support basic sequence comparison model? ver 0.9: - Supported using higher-order function Daniel: - It can be supported using model of ver 0.8 Polar: - Sequence handling in ver 0.8 is not consistent Michiharu: - Should be supported but more limited way (XPath 2.0 model) would be desirable Michiharu Kudo IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC