Re: [xacml] [CR] 0047:Function specification for XPath handler

[Polar Humenn <polar@syr.edu>]

On Mon, 23 Sep 2002, Michiharu Kudoh wrote:

>
> Hi, Polar
>
> I agree to the name function:xpath-node-equal and
> function:xpath-node-count. I would prefer those two functions to
> function:xapth-node-in-common because I intended to use those functions in
> MatchId in addition to Apply element. It seems that we should use *-equal
> and *-match as the function name to show that it is one of the equality
> function. As I posted before, a policy fragment in Rule 1 looks:
>
> <ResourceMatch MatchId="function:xpath-match">
>   <AttributeValue>/md:record</AttributeValue>
>   <ResourceAttributeDesignator AttributeId="urn:...:xpath"/>
> </ResourceMatch>
>
> The function:xpath-match might be named function:xapth-node-match and I
> don't care. The function:xpath-match is a syntax sugar of xpath-node-equal
> but I am sure that we need that function to write a concise policy for XML
> access control. So my preference is to add:
>
> function:xpath-node-equal (optional)
> function:xpath-node-count (optional)
> function:xpath-node-match (optional)
>
> Does it make sense?

The only thing I'm kind of worried about, is that our "xpath-node-equal"
will be different than the "op:node-equal" definition, because our
function xpath-node-equal is effectively a boolean predicate between two
sets of nodes, whereas "op:node-equal" is a boolean predicate between two
nodes, i.e. op:node-equal calls for a "dynamic error" if any argument is
more than one node. However, the definition will be XACML's, so one will
have to carefully read the specification.

I'll try to get these things in the document today.

Cheers,
-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/21 04:57         Subject:  Re: [xacml] [CR] 0047:Function specification for XPath handler
>
>
>
>
>
>
>
> Michiharu,
>
> Ah, thanks for the clarification! So, now I am convinced that the
> op:node-equal means just that, the same exact node, not equivalent nodes
> or even just the same "path". It basically means that a reference points
> to exactly the same place. Good.
>
> Now, op:node-equal is defined arguments of at most one node. otherwise it
> would be "dynamic error", e.g. an argument containing 2 nodes.
>
> Then, how about these names and semantics:
>
>              function:xpath-node-equal
>
> evaluates to the following:
>
>      If here is exactly one node named by each xpath expression
>      and the nodes have the same identity, the result is true.
>      otherwise, if either xpath expression returns an empty node-set, then
>      the result is false, Otherwise, the function is
>      undefined and the result is indeterminate.
>
> Then I believe we should "fill out" the function space to be able to test
> for the number of nodes returned by an Xpath expression:
>
> function:xpath-node-count
>
> This function returns an xs:integer that tells the number of nodes
> returned by the xpath expression. The need for this function is so that
> you may write expressions that don't have to rely on raising an error when
> a multinode situation arises.
>
> If you still want the functionality of finding at least one single node
> between two xpath expressions, we can go for
>
> function:xpath-node-in-common
>
> which I think conveys its semantics a bit better.
>
> What do you think?
>
>
> Cheers,
> -Polar
>
>
> On Fri, 20 Sep 2002, Michiharu Kudoh wrote:
>
> >
> > Polar,
> >
> > I should have written node comparisons (is or isnot) not op:node-equal.
> > Node comparison is described in http://www.w3.org/TR/xpath20/, Section
> > 3.5.3:
> > In the definition of the node identity in XPath data model
> > (http://www.w3.org/TR/query-datamodel/),
> > function node-equal is used. It is a little complicated, but I meant that
> > semantics.
> > I don't mean deep-equal here.
> >
> > ====
> > 3.5.3 Node Comparisons (is or isnot)
> > The result of a node comparison is defined by applying the following
> rules,
> > in order:
> >    1.Each operand must be either a single node or an empty sequence;
> > otherwise a dynamic error is raised.
> >    2.If either operand is an empty sequence, the result of the comparison
> > is an empty sequence.
> >    3.A comparison with the is operator is true if the two operands are
> > nodes that have the same identity; otherwise it is false. A comparison
> with
> > the isnot operator is true if the two operands are nodes that have
> > different identities; otherwise it is false. See [XQuery 1.0 and XPath
> 2.0
> > Data Model] for a discussion of node identity.
> >
> > Use of the is operator is illustrated below.
> >    The following comparison is true only if the left and right sides each
> > evaluate to exactly the same single node:
> >
> > //book[isbn="1558604820"] is //book[call="QA76.9 C3845"]
> > ====
> >
> > So in our case,
> > (xpath-equal "//md:patient[md:first='Alice']/ "//md:patient[md:last
> > ='Johnson']")
> > shall return true if both xpath returns the identical node, <md:patient>.
> >
> > <md:patient>
> >   <md:first>Alice</md:first>
> >   <md:last>Johnson</md:last>
> > </md:patient>
> >
> > Does it make sense?
> >
> > 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/20 04:39         Subject:  Re: [xacml] [CR]
> 0047:Function specification for XPath handler
> >
> >
> >
> >
> >
> >
> >
> > Michiharu,
> >
> > You have refered me to "op:node-equal" for your desired fucntion
> > "xacml:xpath-equal". This specification states that two nodes are equal
> in
> > this sense if they have the same identity.
> >
> > I'm confused on this notion of node identity. So, hopefully you can
> > resolve my confusion. It appears that the name of a node is its fully
> > qualified path by its element names (I think).
> >
> > In your example you have
> >
> > <Apply FunctionId="function:xpath-equal">
> >   <AttributeValue>/Request/Subject/Attribute[@AttributeId
> > ="role"]/AttributeValue
> >   </AttributeValue>
> >   <AttributeValue>/Request/Subject/Attribute[@AttributeId
> > ="role"]/AttributeValue
> >   </AttributeValue>
> > </Apply>
> >
> > Noting that the two XPATH expressions are the same, and let's say the
> > particular "role" attribute of the request context contains "Doctor" are
> > you comparing:
> >
> > 1.   "/Request/Subject/Attribute/AttributeValue" to
> >      "/Request/Subject/Attribute/AttributeValue", or
> >
> > 2.   "Doctor" to "Doctor"
> >
> > The semantics in the:
> >
> > > http://www.w3.org/TR/xquery-operators/
> > > Please see section 13.1.6
> >
> > seems to suggest that 1 is the case.
> >
> > Are you really looking to use "op:deep-equal"?
> >
> > If you mean op:node-equal you must pick out the same node by name. This
> > really means that we are really only comparing their XPATH expressions to
> > see if they correspond.
> >
> > (xpath-equal "//md:record/*" "//md:record/name")
> >
> > would always be true, regardless, because although the "//md:record/*"
> can
> > match any //md:record/FavoriteElementNameHere.
> >
> > I'm just confused. Help!
> >
> > -Polar
> >
> >
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > 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>
>