MHonArc v2.5.2 -->
xacml message
[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