[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Proposal of Model for comparing two sequences
Michiharu, Convoluting the SIMPLE apply function is a bad idea. Not only that, you'd have to do so for the Condition construct as well. For example, what would the following be: <Apply FunctionId="function:integer-subtract" ComparisonBase="ANY"> <AttributeValue>10</AttributeValue> <AttributeValue>20</AttributeValue> </Apply> -Polar On Thu, 12 Sep 2002, Michiharu Kudoh wrote: > > This includes a proposal document (pdf and word format) of model for > comparing two sequences. > > As far as I understand, the model for comparing two sequences in function > draft 0.8 seems not sufficient for comparison (matching) framework. I am > assuming that our data model supports a sequence as a base type. For > example, type-member-of function supports only equality comparison but not > other kinds of comparison such as string-greater-than etc. My opinion is > that we need to specify two things: how to compare two sequences and how to > compare each element. In the following example, > > >(resourceMatch string-equal ["Michiharu","Polar","Daniel"] "Daniel") > >evualates to True. > > The above means that whether ANY element of the first sequence matches the > value of the second argument. This corresponds to "how to compare > sequences". The string-equal corresponds to "how to compare each element". > According to the current function draft, it is specified: > > In <Target>: > <Resource MatchId="function:string-equal"> > <AttributeSelector RequestContextPath="/a/b/c/text()"> > <AttributeValue>Daniel</AttributeValue> > </Resource> > > In <Condition>: > <Apply FunctionId="function:string-member-of"> > <AttributeValue>Daniel</AttributeValue> > <AttributeSelector RequestContextPath="/a/b/c/text()"> > </Apply> > > In this case, /a/b/c/text() returns ["Michiharu", "Polar", "Daniel"]. > I would like to specify this without using string-member-of: > > <Apply FunctionId="function:string-equal" ComparisonBase="ANY"> > <AttributeSelector RequestContextPath="/a/b/c/text()"> > <AttributeValue>Daniel</AttributeValue> > </Apply> > > "ANY" means that means that it compares each element of the first sequence > with the second argument. If none of the comparisons becomes true, then the > result of this comparison becomes false. Other wise, the result becomes > true. This is more generic because you can specify other functions (e.g. > integer-equal and integer-greater-than) in FunctionId attribute like: > > (resourceMatch integer-equal [100,200,300],100) > <Apply FunctionId="function:integer-equal" ComparisonBase="Each"> > <AttributeSelector RequestContextPath="/a/b/c/text()"> > <AttributeValue>100</AttributeValue> > </Apply> > > (resourceMatch integer-greater-than [100,200,300],50) > <Apply FunctionId="function:integer-greater-than" ComparisonBase="Each"> > <AttributeSelector RequestContextPath="/a/b/c/text()"> > <AttributeValue>50</AttributeValue> > </Apply> > > The above examples cannot be handled by the functions defined in the > current draft. > The following is my proposal of "model of sequence comparison" that > summarizes comparison patterns like "ANY" (I use a slightly different > definition from the above). There is no need to define functions like > "string-equal-memeber-of" and "string-match-member-of" but we can get the > same functionality. > (See attached file: XACMLSequenceComparison.doc)(See attached file: > XACMLSequenceComparison.pdf) > > 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 '" <xacml@lists.oasis-open.org> > 2002/09/11 00:52 Subject: Re: [xacml] Data model in function > > > > > > > > The answer to your question would be B. (only if you use the ResourceMatch > with "string-equal", as opposed to "string-match"). > > There is nothing inconsistent with the data model. > > The semantics of ResourceMatch allows matching using different functions, > i.e. string-equal, string-match. > > The definition, of which I already I already posted in, > http://lists.oasis-open.org/archives/xacml/200209/msg00040.html > for ResourceMatch is: > > resourceMatch f [] a = False > resourceMatch f (b:bs) a = (f a b) || (resourceMatch bs a) > > > NB:: (b:bs) matches a sequence where b is the head element and bs is the > rest. function application is by juxtaposition. || is an infix > logical OR operator. [] is the empty sequence. > > The symbol "f" represents the function applied, such as "string-match", or > string-equal. The expression: > > (resourceMatch string-equal ["Miciharu","Polar","Daniel"] "Daniel") > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > result of resource designator > > evualates to True. > > (resourceMatch string-match ["Michiharu","Polar","Daniel"] "Z.*") > > evaluates to False. > > Unforunately, we are limited in the way in which we can perform this > operation in the "Apply" construct using our standard functions, because > some people were adverse to using a higher order expressions, such as the > in the semantic definition above. > > For the Apply construct, using the "string-member-of" is defined as > strictly using apply the "string-equal" function to each member of the > sequence. So, getting some other function applied such as "string-match" > is problematic. > > If you want the same capability in the apply construct we can just expand > the number of functions, such as "string-equal-memeber-of" and > "string-match-member-of" to get the differing functionality. But I haven't > heard a call for that functionality, yet. :) > > Cheers, > -Polar > > On Tue, 10 Sep 2002, Michiharu Kudoh wrote: > > > > > Hi, Polar and Daniel > > > > What I am concerned is a potential difference in data model between > *Match > > function and *Apply function. Assume that the following policy fragment > is > > correct. (Polar said so since *Match function implicitly supports > > comparison between each value of the sequence and a constant value using > > existential comparison). > > > > <ResourceMatch MatchId="function:string-equal"> > > <AttributeSelector RequestContextPath="/a/b/c/text()"> > > <AttributeValue>bb1</AttributeValue> > > </ResourceMatch> > > > > How should the above policy be mapped to an expression specified in the > > condition? A), B), or other? > > > > A) > > <Apply FunctionId="function:string-equal"> > > <AttributeSelector RequestContextPath="/a/b/c/text()"> > > <AttributeValue>bb1</AttributeValue> > > </Apply> > > > > B) > > <Apply FunctionId="function:string-member-of"> > > <AttributeValue>bb1</AttributeValue> > > <AttributeSelector RequestContextPath="/a/b/c/text()"> > > </Apply> > > > > My opinion is that if we use the same data model in both *Match function > > and *Apply function, we should use the same policy specification (case > A). > > If we use different data model, then the mapping should be explicitly > > described. > > > > Michiharu Kudo > > > > IBM Tokyo Research Laboratory, Internet Technology > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 > > > > > > > > > > > > Polar Humenn > > <polar@syr.edu> To: Daniel Engovatov > <dengovatov@crosslogix.com> > > cc: Michiharu > Kudoh/Japan/IBM@IBMJP, "'XACML '" <xacml@lists.oasis-open.org> > > 2002/09/09 22:35 Subject: RE: [xacml] [CR] > AttributeSelectorIndirect > > > > > > > > > > > > > > On Fri, 6 Sep 2002, Daniel Engovatov wrote: > > > > > My guess that in your example what you really want to use > > > are functions string-member-of and integer-member-of. > > > > No. The *Match function semantics have that capability. You specify with > > the MatchID the function that does the individual comparisons. This > > approach lets you specify predicates that aren't just based on equality, > > such as some regular expression matching function. > > > > -Polar > > > > > > > In this case if the selector returns more then one value, at > > > least one should match. It fits the current type model. > > > > > > For integer-member-of - value returned by the selector will > > > be converted to integer value and numerical comarison will be used. > > > Result will be INDETERMINATE if the conversion could not be > > > performed. > > > > > > daniel; > > > > > > --------------------- > > > <ResourceMatch MatchId="function:string-equal"> > > > <AttributeSelector RequestContextPath="/a/b/c/text()"> > > > <AttributeValue>bb1</AttributeValue> > > > </ResourceMatch> > > > > > > The first attribute selector may return a sequence of primitive types > > > (e.g. > > > bb1 and bb2). Then what is the semantics of the function:string-equal? > > > Does > > > that compare each of the return value of the attribute selector with > > > "bb1"? > > > > > > What if function:integer-equal is used? > > > > > > <ResourceMatch MatchId="function:integer-equal"> > > > <AttributeSelector RequestContextPath="/a/b/@b1"> > > > <AttributeValue>100</AttributeValue> > > > </ResourceMatch> > > > > > > Comparison is done based on numeric comparison? > > > > > > 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 > > > <xacml@lists.oasis-open.org> > > > > > > 2002/09/06 22:14 Subject: Re: [xacml] > > > [CR] AttributeSelectorIndirect > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Michiharu, > > > > > > Comments are inline. > > > > > > On Fri, 6 Sep 2002, Michiharu Kudoh wrote: > > > > > > > > > > > Polar > > > > > > > > I have a couple questions. > > > > > > > > 1. How to mandate a returned data from the attribute selector to be a > > > > sequence of a specific type? Are you suggesting to specify DataType > > > > attribute in the attribute selector element? > > > > > > You always must apply a function to any result of an attribute > selector. > > > That function specifies the types of its formal parameters, and > > > therefore > > > implies the type of the attribute selector. You said so yourself for > > > AttributeValues. > > > > > > > 2. I am not clear on how to specify resource match using > > > > function:string-equal. Is the following policy fragment correct if > the > > > > attribute selector returns a sequence of a primitive type (string > type > > > > because function:string-equal implies that)? > > > > > > > > <ResourceMatch MatchId="function:string-equal"> > > > > <AttributeSelector RequestContextPath="/a/b/@b1/"> > > > > <AttributeSelector RequestContextPath="/a/b/c/text()"/> > > > > </ResourceMatch> > > > > > > This example is wrong. The second element of a ResourceMatch must be a > > > primitive value, currently an explicit AttributeValue. > > > > > > <ResourceMatch MatchId="function:string-equal"> > > > <AttributeSelector RequestContextPath="/a/b/@b1/"> > > > <AttributeValue>bb1</AttributeValue> > > > </ResourceMatch> > > > > > > However, if you really want to put a "value" as the second argument, of > > > which I cannot see a good argument against, it would require a SCHEMA > > > CHANGE. > > > > > > Given that we agree with that, If you believe the /a/b/c/text() will > > > return a sequence of one you would use: > > > > > > <ResourceMatch MatchId="function:string-equal"> > > > <AttributeSelector RequestContextPath="/a/b/@b1/"> > > > <Apply FunctionId="string-first-and-only"> > > > <AttributeSelector > > > RequestContextPath="/a/b/c/text()"/> > > > </Apply> > > > </ResourceMatch> > > > > > > If for some reason, your resource data model is screwed up, and your > > > "/a/b/c/text()" attribute selector returns a sequence of more than one > > > or > > > empty, you will get an Indeterminate (i.e. an error). > > > > > > > 3. I want to see specification examples how to use each function in > > > Match > > > > element and Condition element. > > > > > > Above is one example. > > > > > > > Sample XACML Contexts and policy specifications would be helpful to > > > > understand how to use functions. Otherwise, I cannot have a clear > > > > mapping between XPath 1.0 (and 2.0) functions and XACML functions. > > > > > > Is the above enough to get the point across? > > > > > > -Polar > > > > > > > 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 > > > <xacml@lists.oasis-open.org> > > > > 2002/09/05 23:01 Subject: Re: [xacml] > > > [CR] > > > AttributeSelectorIndirect > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Michiharu, > > > > > > > > Comments inline. > > > > > > > > On Wed, 4 Sep 2002, Michiharu Kudoh wrote: > > > > > > > > > > > > > > Hi, Polar > > > > > > > > > > I think that the policy syntax I posted before can be consistent > > > with > > > the > > > > > functions and data types specified in the latest draft of XACML > > > standard > > > > > function. (when I first proposed, there was no notion of sequence > > > data > > > > > type) Since XACML supports a sequence and a set data types, > > > functions > > > > that > > > > > processes XPath expressions can be mapped to those data types. > > > > > > > > > > Basically XPath 1.0 defines a return type as an object data type > > > > > (either node-set, boolean, number, or string). To define a mapping > > > > > rule from XPath object data type to XACML sequence data type would > > > be > > > > > a choice, I think. The problem would be that "node-set" of XPath is > > > > > different from "sequences of primitive types". It is not a sequence > > > of > > > > > primitive-type data but just a set of (DOM) nodes which may include > > > a > > > > > structured node. But if we ignore that structured node case, it > > > would > > > > > be easy to map node-set to "sequence of primitive type". Then the > > > > > definition of <AttributeSelector> processes XPath expressions and > do > > > a > > > > > data conversion. Examples are the following: > > > > > > > > > > Suppose there is a XML document: > > > > > <a a1="aaa"> > > > > > <b b1="bb1"> > > > > > <c>bb1</c> > > > > > </b> > > > > > <b b1="bb2"/> > > > > > </a> > > > > > > > > > > Case A: > > > > > XPath expression of "/a/@a1" returns an attribute node: > > > > > attribute node "a1" that contains a text node "aaa" > > > > > > > > I believe we mandate this to be a sequence of a specific type implied > > > by > > > > the function applied to it. Such as if we used > > > "function:string-member-of" > > > > on this result of this XPATH expression its type is implied to be a > > > > sequence of xs:string, for XACML purposes. > > > > > > > > > Case B: > > > > > XPath expression of "/a/b/@b1" returns two attribute nodes "b1": > > > > > attribute node "b1" that contains "bb1" > > > > > attribute node "b1" that contains "bb2" > > > > > > > > Again, I believe we mandate this to be a sequence of a specific type > > > > implied by the function applied to it. If we used > > > > "function:string-memeber-of" it would be considered a sequence of > > > > xs:string containing "bb1" and "bb2". > > > > > > > > > > > > > Case C: > > > > > XPath expression of "/a/b/c/text()" returns a text node: > > > > > text node that contains "xyz" > > > > > > > > again, same thing. > > > > > > > > > Above three cases indicates a natural mapping from node set to a > > > sequence > > > > > of primitive data types. (For simplicity, I ignore primitive data > > > type > > > > > here) > > > > > > > > I agree. > > > > > > > > > Case D: > > > > > XPath expression of "/a/b" returns two notes: > > > > > element node "b" that contains element "c" and attribute "b1" > > > > > element node "b" that contains attribute "b1" > > > > > > > > > > In Case D, there is no natural mapping from returned node set > > > because > > > > > returned object is a structured node. (In XPath 1.0, there is a > > > > conversion > > > > > definition of structured node (as a string value), I don't think it > > > fits > > > > to > > > > > XACML case.) > > > > > > > > > > One possibility would be to raise an error for Case D, or returns > an > > > > empty > > > > > sequence without error. > > > > > > > > I think returning and empty sequence is a REALLY bad idea. If we > > > allowed > > > > this kind of thing, there is no need for a type system or any > > > integrity > > > to > > > > the evaluation of policy against its inputs. > > > > > > > > If you have a node-set that is some type other than the standard > types > > > > that we support, you should use create a type extension and functions > > > that > > > > explicity know how to deal with that extension, otherwise it is an > > > error > > > > (which can quite possibly be handled at compile time). > > > > > > > > > (Anyway, policy writer must be sure that the XPath > > > > > expression really returns sequence of primitive types.) > > > > > Based on the above observation, the following example returns true: > > > > > > > > > > <ResourceMatch MatchId="function:has-string-intersection"> > > > > > <AttributeSelector RequestContextPath="/a/b/@b1/"> > > > > > <AttributeSelector RequestContextPath="/a/b/c/text()"/> > > > > > </ResourceMatch> > > > > > > > > I thinkthe function you would use here would be > > > "function:string-equal" > > > > because the ResourceMatch has the semantics of applying the function > > > named > > > > by MatchId to the elements in the sequences to see if there is a > > > match. > > > > > > > > -Polar > > > > > > > > > For example, function:has-intersection returns true because the > > > first > > > > > argument and the second argument has an intersection ("bb1") as a > > > string > > > > > value. > > > > > > > > > > Michiharu > > > > > > > > > > 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 > > > > <xacml@lists.oasis-open.org> > > > > > 2002/08/30 21:47 Subject: Re: > [xacml] > > > [CR] > > > > AttributeSelectorIndirect > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Michiharu, > > > > > > > > > > Comments inline. > > > > > > > > > > On Fri, 30 Aug 2002, Michiharu Kudoh wrote: > > > > > > > > > > > > > > > > > Line 804-810 of draft 0.16e, there is a resource match in Example > > > 2 > > > > Rule > > > > > 1: > > > > > > > > > > > > <ResourceMatch MatchId="function:node-match"> > > > > > > <ResourceAttributeDesignator AttributeId="urn:...:xpath" > > > > > > DataType="xsi:string"/> > > > > > > <AttributeValue > > > DataType="xsi:string">/md:record</AttributeValue> > > > > > > </ResourceMatch> > > > > > > > > > > > > In the above example, the node-match function is defined as > > > > > > > > > > > > Function: node-match > > > > > > input: xs:string, xs:string > > > > > > output: xs:boolean > > > > > > description: receive two xpath expressions and executes xpath > > > processor > > > > > on > > > > > > both xpaths. It generates two objects (object type is defined in > > > XPath > > > > > 1.0, > > > > > > i.e. node-set, string, numeric, or boolean). When two objects > have > > > an > > > > > > intersection, then it returns true, otherwise return false. > > > > > > > > > > This function, although a little unwieldy, is fine, provided you > can > > > > > provide a deterministic definition for a node-match. ("when two > > > object > > > > > have an intersection") is somewhat lacking. > > > > > > > > > > > Instead of the above node-match function and the resource match > > > > > > specification, I would prefer the definition and resource match > > > > > > specification using <AttributeSelectorIndirect> below: > > > > > > > > > > > > Function: node-match > > > > > > input: object, object > > > > > > output: xs:boolean > > > > > > description: receive two objects. When two node-sets have an > > > > > intersection, > > > > > > then it returns true, otherwise return false. > > > > > > > > > > > > <ResourceMatch MatchId="function:node-match"> > > > > > > <AttributeSelectorIndirect> > > > > > > <ResourceAttributeDesignator AttributeId="urn:...:xpath"/> > > > > > > </AttributeSelectorIndirect> > > > > > > <AttributeSelector RequestContextPath="/md:record"/> > > > > > > </ResourceMatch> > > > > > > > > > > Why? > > > > > > > > > > Your previous approach is fine, and works within our type system. > It > > > > takes > > > > > two arguments of primitive types ("xs:string") and returns an > > > xs:boolean. > > > > > > > > > > This approach requires "node-match" to be polymorphic and for XACML > > > > > processors to understand abstract data types. Our simple type > system > > > > > cannot support it. We would now have much more than primitive > types, > > > and > > > > > sequences of primitive types. We would have abstract data types > > > (i.e. > > > > > arbitrary XML nodes) introduced into the type system. > > > > > > > > > > Also, in this case, you must note that the selectors must contain > > > the > > > > > "DataType" attribute to make type sense out of their results, as > > > these > > > > > selectors can end up in other function applications. I think we > are > > > > > trying to get rid of the DataType attribute, because of the type > > > > > inference. > > > > > > > > > > Also, I think you left the "DataType" attribute out in this > example, > > > for > > > > > obvious reasons. You don't know what legal value to give it. > > > > > > > > > > In both cases, however, you still need to come up with an explicit > > > > > specification of for the function "node-match". > > > > > > > > > > If you can come up with a specification of node-match, I would > > > strongly > > > > > prefer that it was a function that fit with our type system, i.e. > > > your > > > > > first example, which takes two XPATH expressions and returns a > > > boolean. > > > > > > > > > > > > > > > > Other example (not AttributeSelectorIndirect but > AttributeSelector > > > > case) > > > > > is > > > > > > line 825-835. The function:string-equal should be the > > > > > > function:general-string-equal because <AttributeSelector> returns > > > an > > > > > object > > > > > > data type (maybe node-set) and it is not proper to hand it to > > > > > string-equal > > > > > > function. > > > > > > > > > > I don't even have a specification for "string-equal", let alone > > > > > "general-string-equal", so I don't really understand the > difference. > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > <Condition FunctionId="function:string-equal"> > > > > > > <SubjectAttributeDesignatorWhere > > > > > > AttributeId="urn:...:policy-number" DataType="xsi:string"/> > > > > > > <AttributeSelector RequestContextPath="/ctx:Request/ ... > > > > > > /md:policyNumber" > > > > > > DataType="xsi:string"/> > > > > > > </Condition> > > > > > > > > > > > > [should be] > > > > > > > > > > > > <Condition FunctionId="function:general-string-equal"> > > > > > > <SubjectAttributeDesignatorWhere > > > > > > AttributeId="urn:...:policy-number" DataType="xsi:string"/> > > > > > > <AttributeSelector RequestContextPath="/ctx:Request/ ... > > > > > > /md:policyNumber" > > > > > > DataType="xsi:string"/> > > > > > > </Condition> > > > > > > > > > > > > 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@lists.oasis-open.org> > > > > > > 2002/08/30 03:27 Subject: Re: > > > [xacml] > > > > [CR] > > > > > AttributeSelectorIndirect > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Michiharu, > > > > > > > > > > > > Is there a use case or example for this type of attribute > > > selector? > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > On Thu, 29 Aug 2002, Michiharu Kudoh wrote: > > > > > > > > > > > > > Based on the discussion on Monday call, Simon and I agreed to > > > > changing > > > > > > the > > > > > > > schema to support an AttributeSelectorIndirect element to > > > retrieve > > > a > > > > > > XPath > > > > > > > expression from the context. I wonder whether the name of this > > > > element > > > > > is > > > > > > > appropriate or not. > > > > > > > > > > > > > > <xs:complexType name="AttributeSelectorBaseType"> > > > > > > > <xs:element ref="xacml:XPathNamespace" minOccurs="0" > maxOccurs > > > > > > > ="unbounded"/> > > > > > > > <xs:attribute name="DataType" type="xs:anyURI" > > > use="optional"/> > > > > > > > <xs:attribute name="XPathVersion" type="xs:anyURI" > > > use="optional" > > > > > > default > > > > > > > ="http://www.w3.org/TR/1999/Rec-xpath-19991116"/> > > > > > > > </xs:complexType> > > > > > > > > > > > > > > <xs:complexType name="AttributeSelectorType"> > > > > > > > <xs:complexContent> > > > > > > > <xs:extension base="AttributeSelectorBaseType"> > > > > > > > <xs:attribute name="RequestContextPath" type="xs:string" > > > use > > > > > > > ="required"/> > > > > > > > </xs:extension> > > > > > > > </xs:complexContent> > > > > > > > </xs:complexType> > > > > > > > > > > > > > > <xs:complexType name="AttributeSelectorIndirectType"> > > > > > > > <xs:extension base="AttributeSelectorBaseType"> > > > > > > > <xs:choice> > > > > > > > <xs:element ref="xacml:SubjectAttributeDesignator"/> > > > > > > > <xs:element ref="xacml:ResourceAttributeDesignator"/> > > > > > > > <xs:element ref="xacml:ActionAttributeDesignator"/> > > > > > > > <xs:element ref="xacml:EnvironmentAttributeDesignator"/> > > > > > > > </xs:choice> > > > > > > > </xs:extension> > > > > > > > </xs:complexType> > > > > > > > > > > > > > > <xs:element name="AttributeSelector" > > > type="AttributeSelectorType"/> > > > > > > > <xs:element name="AttributeSelectorIndirect" type > > > > > > > ="AttributeSelectorIndirectType"/> > > > > > > > > > > > > > > <xs:element name="XPathNamespace" > > > type="xacml:XPathNamespaceType" > > > > > > > substitutionGroup="xacml:AbstractDefaults"/> > > > > > > > <xs:complexType name="XPathNamespaceType"> > > > > > > > <xs:attribute name="NamespaceURI" type="xs:anyURI"/> > > > > > > > <xs:attribute name="Prefix" type="xs:string" use="optional"/> > > > > > > > </xs:complexType> > > > > > > > > > > > > > > > > > > > > > Sample text for this element: > > > > > > > > > > > > > > 5.28. Element <AttributeSelectorIndirect> > > > > > > > > > > > > > > The <AttributeSelectorIndirect> element is a free-form pointing > > > > device > > > > > > into > > > > > > > the <xacml-context:Request> element using an attribute > > > designator. > > > > The > > > > > > > actual xpath expression is retrieved from the context pointed > by > > > that > > > > > > > attribute designator. Other than that, the semantics is the > same > > > with > > > > > > > <AttributeSelector> element. Support for the > > > > > <AttributeSelectorIndirect> > > > > > > > element is OPTIONAL. > > > > > > > > > > > > > > The <AttributeSelectorIndirect> element is of > > > > > > AttributeSelectorIndirectType > > > > > > > complex type. > > > > > > > The <AttributeSelectorIndirect> element has either one of the > > > > following > > > > > > > elements: > > > > > > > > > > > > > > SubjectAttributeDesignator > > > > > > > ResourceAttributeDesignator > > > > > > > ActionAttributeDesignator > > > > > > > EnvironmentAttributeDesignator > > > > > > > > > > > > > > Michiharu > > > > > > > > > > > > > > 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> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > > To subscribe or unsubscribe from this elist use the subscription > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > To subscribe or unsubscribe from this elist use the subscription > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > To subscribe or unsubscribe from this elist use the subscription > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > To subscribe or unsubscribe from this elist use the subscription > > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > To subscribe or unsubscribe from this elist use the subscription > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > ---------------------------------------------------------------- > > > To subscribe or unsubscribe from this elist use the subscription > > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > > > > > ---------------------------------------------------------------- > > 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