All,
I have got into the deep gory details of the multiple/hierarchical
resources profiles, which seem broken regarding the xpath variant of
them (this is not on the issues list yet). I also ended back at the
already closed xpath datatype (issue 78).
The 2.0 hierarchical resources profile defines a new datatype called
...:xpath-expression and mandates the use of this data type for
requesting access for some form of hierarchical resources. The problem
with this is that there is no XACML function which actually makes use of
this data type, so the profile won't work as it stands today.
Also, in case you don't remember, I would remind you about the related
issue that we have decided to introduce an xpath data type for XACML 3.0
and we have defined new 3.0 identifiers for the xpath match functions
which use this new data type instead of strings. The motivation is that
an xpath expression is more than a string in the sense that it also has
a context for resolving namespace prefixes used in the expression. With
strings this is problematic. This new 3.0 xpath-expression data type is
a bit different from the 2.0 one since the 2.0 xpath-expression is
defined to have a value which consists of the node set which results
from evaluating the expression. (In contrast to simply the expression
itself.)
I searched through the XACML TC mailing list to try to understand what
was intended with the 2.0 xpath-expression. (BTW, the search function
seems to be broken. I get an error stating that I am not allowed to
access some perl script on the web server, so I had to use my web
browser's find function on the mailing list archive pages. I might have
missed something because of this.)
I found a discussion about this type at the later stages of the 2.0
work. See the archive for August 2004 and look for the postings with
"xpath" in their subjects.
Back then the main motivation behind the idea to have such a type seems
to have been to introduce type safety and checking of syntactical
validity, rather than the namespace issue. The idea seems to have been
rejected back then because there was a desire to be able to construct
xpath expressions dynamically and the proposal would have made that
impossible. Also, there were objections saying that it was too late in
the 2.0 process to make such a change. However, the data type seems to
have made to the docs and I suspect that it was just forgotten to drop
this from the hierarchical resources profile once the decision was made
that there should be no special xpath-expression data type. The
discussions in August 2004 mention removing the data type from the
examples in the core doc. I might be wrong of course, but all should
work if we just replace the use of this data type with strings in all docs.
Regarding the new 3.0 xpath expression data type, maybe the dynamic
construction of xpath expressions is still a concern? Nobody has raised
this issue in the 3.0 discussion, but it might still be valid. We should
introduce a xpath constructor function which takes a string and converts
it into the xpath data type, which would make dynamic construction of
xpath expression possible. Though, I am not sure how to handle namespace
prefixes here. One option is that no name space prefixes will be
resolvable. Another is that they are resolved from the