Hi Rich,
No, I still don't understand how the identifiers could be used as xpaths
in policies.
I can understand the regexp case. For instance, assume that the request
contains
<Attributes Category="resource">
<Attribute AttributeId="resource-id">
<AttributeValue
Datatype="anyURI">http://example.com/foo#*:bar[namespace-uri='example.com/ns1']</AttributeValue>
...
</Attribute>
...
</Attributes>
then one could do something like this in a policy:
<Match MatchId="urn:....:anyURI-regexp-match">
<AttributeValue Datatype="string">...some regexp here...</AttributeValue>
<AttributeDesignator AttributeId="resource-id" Datatype="anyURI"/>
</Match>
But how would you use the resource-id as an xpath expression? Where
would you put it in the policy and using what construct?
Best regards,
Erik
Rich.Levinson wrote:
> Hi Erik,
>
> You were right about the syntax, there needs to be a leading "*" in
> order to collect "all" the child nodes and then discriminate based on
> local-name() and namespace-uri(). However, I did find the
> "*:<local-name-literal> works as well, so I modified the spec
> (attached) to include a leading "*:" (star-colon) before the
> local-name-literals. I also added a couple of notes to indicate that,
> as well as pointing out that the strings
>
> * /*:abc[namespace-uri()=""]
> * /abc
>
> are equivalent, so that for the no-namespace use cases, there is no
> need for the prefix and predicate.
>
> On the issue of how xacml treats the identifier, I finessed that a bit
> as follows: it is the <fragment> item that is serving as the
> identifier within the XML document itself. So, as specified, it should
> work as an xpathExpression, possibly without the leading "/", in an
> AttributeSelector. The proposed specification says that the
> expressions that conform to the proposed <fragment> layout only need
> to be percent-encoded when put within a URI. So, for example, if one
> wanted to use it as the AttributeValue for a resource-id Attribute,
> there is no technical reason why it needs to be percent-encoded.
>
> Regarding issue 11, the problem was to pin down a consistent syntax so
> that regular expression matching rules could be specified. The
> original proposal I submitted addressed this issue by providing a
> non-xpath syntax in the hierarchical URI scheme, which provided an
> "alternative" representation for identifying the nodes in an XML
> document.
>
> Further analysis of the problem, and especially Paul's raising the
> issue of resource-id's caused me to consider the present proposal,
> which I consider superior to the original proposal because it serves
> to layout a method by which identifiers can be automatically produced
> that can be used by both the XPath representation and the URI
> representation, which potentially provides a clean break between the
> naming of the node and the accessing of the node. The particular XPath
> syntax proposed appears to enable the separation of these two
> operations so that the literal XPath expressions can be used either as
> literal identifiers or operational language statements, that
> "identify" the node in the former case and "access" the node in the
> latter case..
>
> Hopefully, the above comments address the concerns you raised.
>
> Thanks,
> Rich
>
>
>
> Erik Rissanen wrote:
>> Rich,
>>
>> You say that the identifier serves as"an executable expression that
>> can be applied to an XML document". That is true from a threoretical
>> point of view, but there are currently no XACML functions which can
>> operate on an URI like this. The URI needs to be resolved and then
>> the path needs to be extracted before it can be applied as an XPath
>> expressions. So it is a fundamentally new scheme, not a modification
>> to the XPath scheme which started issue #11.
>>
>> BTW, did you check the XPath syntax? If I recall correctly from the
>> past, foo[namespace-uri="bar"] does not work. I think I had to do
>> *[localname='foo'][namespace-uri='bar']. I could be wrong though...
>>
>> Best regards,
>> Erik
>>
>> Rich.Levinson wrote:
>>> To TC:
>>>
>>> As described in previous email:
>>> http://lists.oasis-open.org/archives/xacml/200911/msg00042.html
>>> I have revised the original proposal submitted for issue 11.
>>>
>>> This proposal is intended to address the same problems as the
>>> previous proposal, and it also provides a format which can
>>> potentially be used to address the resource-id naming issue raised
>>> by Paul Tyson:
>>> http://lists.oasis-open.org/archives/xacml/200911/msg00032.html
>>>
>>> A summary of expected benefits from this proposal includes the
>>> following:
>>>
>>> * The proposal provides an automatic naming method for any node in
>>> an XML document, in the form of an XPath path expression, that
>>> may also be used to retrieve the actual node identified.
>>> * The proposal shows how to map this expression into standard URI
>>> format by percent encoding each XPath step component that
>>> follows a URI fragment slash "/".
>>> * An XPath step in the proposal is represented by the
>>> concatenation of 3 strings as a local-name plus two optional
>>> predicates, each of which is immediately determinable when in
>>> the XPath context of the document using standard XPath
>>> functions: local-name(), namespace-uri(), and position() and the
>>> full set of steps in the expression can be used to obtain the
>>> single node addressed from any XPath context because the path is
>>> absolute.
>>> * The unencoded XPath path expression can be used as the identity
>>> of a node in an XML document as described in section 2.1 of the
>>> hierarchical profile.
>>> * The unencoded XPath expression can be used as the resource-id as
>>> described in section 2.2.3 of the Multiple Resource Profile.
>>> * The XPath path expression can be used with or without the
>>> associated XML document. i.e. the expression serves as BOTH an
>>> executable expression that can be applied to an XML document AND
>>> a literal identifier that can be used by regular expression
>>> matching type operations.
>>> * Percent-encoding of the XPath path expression is only required
>>> when the expression is used as an actual URI, such as when
>>> extending the URI mechanism into XML documents to identify
>>> entities within the document, or when used as an identifier that
>>> requires URI syntax such as an XML AttributeId attribute.
>>> * In general, because the XPath path expression can operate as a
>>> literal identifier, it enables policies to be written against
>>> resources within XML documents which enable policy evaluation
>>> before the document is accessed.
>>>
>>> I will try to prepare a slide presentation prior to the F2F. In the
>>> meantime, hopefully, the information is intended to be
>>> self-explanatory.
>>>
>>> Comments and suggestions welcome.
>>>
>>> Thanks,
>>> Rich
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail. Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
