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] 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]