Re: [xacml] New working drafts posted

[Erik Rissanen <erik@axiomatics.com>]

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