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


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]