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


2.0 specifies the default context node as xacml-context:Request.  3.0 is
changing the name of the attribute (from RequestContextPath to Path) and
the allowable scope of xpath expressions anyway, so there is no concern
of backwards compatibility.  Implementations will either use the 2.0
scheme or the 3.0 scheme--there will be no interoperability in this
area.  And the paradigm has shifted considerably, so I don't see any
benefit of trying to maintain similarity for ease of migration.

I believe the 3.0 specification would be defective if an xpath
expression in XACML space can select the xacml:Content element (or any
other node from the xacml request context outside of xacml:Content).
The notional XML data structure for AttributeSelector operations should
only include real user content.  The simplest, most reliable way to do
this is to revise the schema to restrict the content of xacml:Content to
one child element from a foreign namespace, and to make this singleton
child the document element for xpath operations.

Regards,
--Paul

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Saturday, December 19, 2009 05:21
> To: Tyson, Paul H
> Cc: xacml
> Subject: Re: [xacml] New working drafts posted
> 
> Paul,
> 
> I could live with that restriction, but I think it is 
> unnecessary, and is different than what XACML 2.0 has, so it 
> could cause annoyances for people migrating from 2.0 to 3.0.
> 
> We could specify the <Content> element node as the context 
> node, not the document element, in which case you just need 
> to write "./MyContent....", or shorter "MyContent...."
> 
> Best regards,
> Erik
> 
> 
> 
> On 12/18/2009 04:40 PM, Tyson, Paul H wrote:
> > I agree there is a lot of ambiguity in the various XML data 
> models and 
> > implementations.  It is difficult to specify a reliable way of 
> > constructing the XML content that will be tested in a XACML context.
> >
> > But I do not think the data structure should include the 
> xacml:Content 
> > element.  If xacml:Content is the document element, then 
> "/*" returns 
> > the element node, "xacml:Content".  I would have to write "/*/*" to 
> > get to my content.
> >
> > I propose modifying the schema to limit the xacml:Content 
> element to 
> > one element child, and specifying that this element will become the 
> > document element of the XML data structure that is 
> accessible to XACML 
> > xpath expressions.  This should be easy to implement by 
> constructing a 
> > new document object from the child element of xacml:Content.  
> > Processing instructions and comments from the<Content>  
> element could 
> > be added to the newly constructed document node.  There would be no 
> > place for xml attributes of<Content>, however, so those should be 
> > disallowed in the schema.
> >
> > Regards,
> > --Paul
> >
> >    
> >> -----Original Message-----
> >> From: Erik Rissanen [mailto:erik@axiomatics.com]
> >> Sent: Friday, December 18, 2009 02:54
> >> To: Tyson, Paul H
> >> Cc: xacml
> >> Subject: Re: [xacml] New working drafts posted
> >>
> >> On 2009-12-17 23:57, Tyson, Paul H wrote:
> >>      
> >>> "/" 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.
> >>>
> >>>        
> >> Yes, you are right. I was confused about the document element.
> >>
> >>      
> >>> 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".
> >>>
> >>>        
> >> I have concerns about implementation costs. I don't want to have a 
> >> spec which cannot be implemented with typical XPath 
> implementations 
> >> available off the shelf. And I don't think it is a good 
> idea to leave 
> >> something ambiguous, given that there is no harm done by having 
> >> a<Content>  element visible for the xpath.
> >>
> >> I just wrote a small test program like this:
> >>
> >> package com.axiomatics.xpathtest;
> >>
> >> --8<--
> >> package com.axiomatics.xpathtest;
> >>
> >> import java.io.File;
> >>
> >> import javax.xml.parsers.DocumentBuilder;
> >> import javax.xml.parsers.DocumentBuilderFactory;
> >>
> >> import org.w3c.dom.Document;
> >> import org.w3c.dom.Node;
> >>
> >> public class Main {
> >>
> >>       static public void main(String[] args) throws Exception {
> >>           DocumentBuilderFactory dbfact = 
> >> DocumentBuilderFactory.newInstance();
> >>           dbfact.setNamespaceAware(true);
> >>           DocumentBuilder db = dbfact.newDocumentBuilder();
> >>
> >>           String filename1 = "doc1.xml";
> >>           Document indoc1 = db.parse(new File(filename1));
> >>
> >>           db.reset();
> >>           String filename2 = "doc2.xml";
> >>           Document indoc2 = db.parse(new File(filename2));
> >>
> >>           Document strangedoc = db.newDocument();
> >>
> >>           Node inputNode1 =
> >> strangedoc.importNode(indoc1.getDocumentElement(), true);
> >>           strangedoc.appendChild(inputNode1);
> >>
> >>           Node inputNode2 =
> >> strangedoc.importNode(indoc2.getDocumentElement(), true);
> >>           strangedoc.appendChild(inputNode2);
> >>       }
> >> }
> >> --8<--
> >>
> >> It will throw an exception at the last line of the main method:
> >>
> >> Exception in thread "main" org.w3c.dom.DOMException:
> >> HIERARCHY_REQUEST_ERR: An attempt was made to insert a 
> node where it 
> >> is not permitted.
> >>       at
> >> com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.insert
> >> Before(Unknown
> >> Source)
> >>       at
> >> com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(Un
> >> known Source)
> >>       at com.axiomatics.xpathtest.Main.main(Main.java:31)
> >>
> >> So the standard java DOM implementation does not allow multiple 
> >> element children of a document node. An implementation 
> would need to 
> >> implement a custom XML/XPath processor.
> >>
> >> Best rergards,
> >> Erik
> >>
> >>
> >>      
> 
> 


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