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
xacml-3.0-hierarchical-v1-spec-cd-1-en-rich-uri-xml-3c.doc
