MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] Issues list and tentative resolutions of function model
Thank you for your correction. To me, all and any are a little confusing...
:-)
Best
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Polar Humenn
<polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP
cc: XACML TC <xacml@lists.oasis-open.org>
2002/09/18 21:45 Subject: Re: [xacml] Issues list and tentative resolutions of function model
Michiharu,
You still have one mistake in your correction for issue 0042. I believe
you intended to use the "function:any-of", since that was in your
argument. However, your corrected text mistakenly used "all-of".
> We fix the above problem by using the higher-order bag function specified
> in 0.9 function draft:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeValue>bbb</AttributeValue>
> <AttributeDesignator AttributeId="role1"/>
> </ResourceMatch>
>
> <Apply FunctionId="function:all-of">
^^^^^ should be "any-of"
> <Function FunctionId="function:string-equal"/>
> <AttributeValue>bbb</AttributeValue>
> <AttributeDesignator AttributeId="role1"/>
> </Apply>
>
> When we specify policy for MatchId, function:all-of is implicitly used
> for specifying the semantics of the comparison on bags.
Cheers,
-Polar
On Wed, 18 Sep 2002, Michiharu Kudoh wrote:
> There is one correction about Issue 0042.
> A function:any-of-each allows a sequence for the second argument but the
> current
> schema allows a value (not a sequence) for the second argument. It
> corresponds
> to function:all-of or function:any-of. From the nature of MatchId,
> function:all-of is
> more appropriate. Then the original description and its correction are:
>
> ==== original ====
> 0042. [Michiharu] XACML supports consistent specification between MatchId
> function and Apply function
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> In ver 0.8 function draft, string comparison (set against a value) is
> differently specified in MatchId from Apply. Suppose attribute selector
> returns a sequence (e.g. "aaa" and "bbb"). In ResourceMatch,
> function:string-equal is used while in Apply, function:string-member-of
> is used:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> <AttributeValue>bbb</AttributeValue>
> </ResourceMatch>
>
> |<Apply FunctionId="function:string-member-of">
> <AttributeValue>bbb</AttributeValue>
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> </Apply>
>
> We fix the above problem by using the higher-order bag function specified
> in 0.9 function draft:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeDesignator AttributeId="role1"/>
> <AttributeValue>bbb</AttributeValue>
> </ResourceMatch>
>
> <Apply FunctionId="function:any-of-each">
> <Function FunctionId="function:string-equal"/>
> <AttributeDesignator AttributeId="role1"/>
> <AttributeValue>bbb</AttributeValue>
> </Apply>
>
> When we specify policy for MatchId, function:any-of-each is implicitly
used
> for specifying the semantics of the comparison on bags.
>
> ==== corrected ====
> 0042. [Michiharu] XACML supports consistent specification between MatchId
> function and Apply function
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> In ver 0.8 function draft, string comparison (set against a value) is
> differently specified in MatchId from Apply. Suppose attribute selector
> returns a sequence (e.g. "aaa" and "bbb"). In ResourceMatch,
> function:string-equal is used while in Apply, function:string-member-of
> is used:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeValue>bbb</AttributeValue>
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> </ResourceMatch>
>
> |<Apply FunctionId="function:string-member-of">
> <AttributeValue>bbb</AttributeValue>
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> </Apply>
>
> We fix the above problem by using the higher-order bag function specified
> in 0.9 function draft:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeValue>bbb</AttributeValue>
> <AttributeDesignator AttributeId="role1"/>
> </ResourceMatch>
>
> <Apply FunctionId="function:all-of">
> <Function FunctionId="function:string-equal"/>
> <AttributeValue>bbb</AttributeValue>
> <AttributeDesignator AttributeId="role1"/>
> </Apply>
>
> When we specify policy for MatchId, function:all-of is implicitly used
> for specifying the semantics of the comparison on bags.
> ==========
>
> Michiharu Kudo
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
>
>
> ----- Forwarded by Michiharu Kudoh/Japan/IBM on 2002/09/18 20:12 -----
>
> Michiharu Kudoh
> To: XACML TC
<xacml@lists.oasis-open.org>
> 2002/09/17 19:55 cc:
> From: Michiharu
Kudoh/Japan/IBM@IBMJP
> Subject: [xacml] Issues
list and tentative resolutions of function model
>
>
>
>
>
>
> The following are the issues list and tentative resolutions of the call
on
> 16. This is not a schema change request but I followed the format used by
> Anne. For the moment I put my name as an initiator of each issue. Please
> let me know any editorial, technical and general comments.
>
>
> 0042. [Michiharu] XACML supports consistent specification between MatchId
> function and Apply function
> STATUS: APPROVED 9/16 (NQ)
>
> 0043. [Michiharu] XACML supports unordered set that is called a "bag"
> STATUS: APPROVED 9/16 (NQ)
>
> 0044. [Michiharu] XACML distinguishes singleton data from bag type
> STATUS: APPROVED 9/16 (NQ)
>
> 0045. [Michiharu] XACML supports higher-order bag functions
> STATUS: APPROVED 9/16 (NQ)
>
> 0046. [Michiharu] XACML supports operators for computing on bag types.
> STATUS: APPROVED 9/16 (NQ)
>
> ======================
> 0042. [Michiharu] XACML supports consistent specification between MatchId
> function and Apply function
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> In ver 0.8 function draft, string comparison (set against a value) is
> differently specified in MatchId from Apply. Suppose attribute selector
> returns a sequence (e.g. "aaa" and "bbb"). In ResourceMatch,
> function:string-equal is used while in Apply, function:string-member-of
> is used:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> <AttributeValue>bbb</AttributeValue>
> </ResourceMatch>
>
> |<Apply FunctionId="function:string-member-of">
> <AttributeValue>bbb</AttributeValue>
> <AttributeSelector RequestContextPath="/a/b/c/text()">
> </Apply>
>
> We fix the above problem by using the higher-order bag function specified
> in 0.9 function draft:
>
> <ResourceMatch MatchId="function:string-equal">
> <AttributeDesignator AttributeId="role1"/>
> <AttributeValue>bbb</AttributeValue>
> </ResourceMatch>
>
> <Apply FunctionId="function:any-of-each">
> <Function FunctionId="function:string-equal"/>
> <AttributeDesignator AttributeId="role1"/>
> <AttributeValue>bbb</AttributeValue>
> </Apply>
>
> When we specify policy for MatchId, function:any-of-each is implicitly
used
> for specifying the semantics of the comparison on bags.
>
>
> 0043. [Michiharu] XACML supports unordered set that is called a "bag"
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> XACML supports an unordered set type and does not support a sequence
> type because there is few requirement that needs sequence dependent
> policy specification (e.g. sequence-equal function (or point-wise
> comparison)
> in XPath 2.0 draft is one of such requirement but TC members decided
> that is a lower priority).
> We rename it from "sequence (unordered set)" to "bag".
>
>
> 0044. [Michiharu] XACML distinguishes singleton data from bag type.
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> XACML has two kinds of functions: a function that defines semantics on
> singleton data (e.g. function:string-equal), and a function that defines
> the
> semantics on bags (e.g. function:any-of-each). This means that XACML
> distinguishes singleton data from bag type. We don't distinguish them by
> local name or its prefix. The specification lists function names as text.
>
>
> 0045. [Michiharu] XACML supports higher-order bag functions
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> XACML supports higher-order bag functions as 0.9 draft describes.
>
>
> 0046. [Michiharu] XACML supports operators for computing on bag types.
> http://lists.oasis-open.org/archives/xacml/200209/msg00098.html
>
> Comparison among bag types (e.g. any-of-each) is defined by higher-order
> bag functions as 0.9 draft describes.
>
> Best
> Michiharu Kudo
>
> IBM Tokyo Research Laboratory, Internet Technology
> Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
>
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC