[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] New working drafts posted
> -----Original Message----- > From: Erik Rissanen [mailto:erik@axiomatics.com] > Sent: Thursday, December 17, 2009 13:23 > To: Tyson, Paul H > Cc: xacml > Subject: Re: [xacml] New working drafts posted > Paul: > > I think that xacml:Content belongs in the XACML world, and its > > children belong in the user's world. The<Content> element is a > > wrapper that should not be visible or accessible during > policy evaluation. > > > > We should define this in terms of the xpath data model > (XDM) instance > > that will be created from xacml:Content, which will be the > subject of > > any xpath expression evaluations. The "sequence of nodes" I > > originally proposed will not work. I propose the model be > specified as: > > > > 1. A new document node will be created for each<Content> element. > > 2. All xml content of the xacml:Content element will be > parsed and put > > into the xpath data model as specified by the xpath data model > > specification (http://www.w3.org/TR/xpath-datamodel). > > > > (This is a notional specification only--there is no > requirement that > > the implementation actually do this--only that the results of xpath > > evaluation are the same as if this had been done.) > > > > Note that this could result in a valid XDM structure that would be > > malformed XML, because the document node could have several element > > children. (In an XDM constructed from valid XML, the document node > > would have only one element child--the document element.) I do not > > see anything that prohibits this, either in the XDM or the Xpath > > specification. > > > Erik: > Yes, the content belongs to the XACML world, but I think it > is perfectly fine as a place holder. A policy belongs to the > XACML world and having a content element as the starting > point of expressions seems fine for me. > > I am not sure if I understand what you propose. The data > model is part of XPath 2.0. Will your approach work with 1.0? It is not as well specified in 1.0. See http://www.w3.org/TR/1999/REC-xslt-19991116#data-model. > > From my experience about using the java xpath API, it > requires a DOM and absolute xpaths don't work correctly if > the document element of the DOM is not set. I see in the spec > for the XPath data model that a document node is not required > to contain exactly one element child, but what would "/" > resolve to in your approach? "/" in xpath 2 is defined as the result of the function fn:root() applied to the context node. fn:root() must return the document-node ancestor of the context node. In xpath 1 it would be the "root node". Neither root *node* nor document *node* is the same as the document *element*, which is the distinguished element that is the only element child of the document (or root) *node* when the data structure is constructed from a well-formed XML document. So if the Content element had: <xacml:Content> <myns:foo/> <myns:foo/> <myns:foo/> </xacml:Content> then "/" would select the document node of the XDM instance, and "/*" would return a sequence of 3 "myns:foo" element nodes. I do not think it would be a problem if the behavior for xpath 1.0 were underspecified in this area, with a recommendation to "approximate the behavior of 2.0 as much as possible". Regards, --Paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]