|
Michiharu,
I see that you want to compute
the node-set of xpath expression specified in
the request-context before passing it to the node-match function.
Of course, something like that could be
accomplished in the condition
with 'xpath-expr' function:
<Apply
FunctionId="function:node-match">
<Apply
FunctionId="function:xpath-expr">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
DataType="xs:string"/>
</Apply>
<AttributeSelector
RequestContextPath="..."/>
</Apply>
You want to do the same thing in the
target.
I'm not completely sold on your syntax for
AttributeSelector. I'd prefer this extension:
<AttributeSelector indirect="true"> (or
IndirectAttributeSelector)
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
DataType="xsi:string"/>
</AttributeSelector>
Better yet to relax 'match' element to allow
'apply' children.
Another approach:
I think that complication is in 'node-match'
function definition that takes --results--
of xpath expression. That forces you to produce
this result, so you
need additional semantics in
attribute-selector.
Consider different function that takes
--xpath-expressions-- as arguments
(as in examples in section 3). Than you do not have
to produce node sets
before calling this function and no change in
schema is needed.
Suppose that node-match-1 has exact same
semantics as node-match but
take 2 xpath expressions: xpath-expr-request and
xpath-expr-rule:
node-match-1(xpath-expr-req, xpath-expr-rule).
You can use it in the target:
<ResourceMatch
MatchId="function:node-match-1">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
DataType="xsi:string"/>
<AttributeValue
DataType="xsi:string">//md:record</AttributeValue>
</ResourceMatch>
Simon
|