OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Revised proposal for issue #11, using XPath/URI pathexpressions


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:
4B0A87B4.6000103@axiomatics.com" type="cite">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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]