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