Re: [xacml] New working drafts posted

[Erik Rissanen <erik@axiomatics.com>]

Paul,

I would be fine with the "singleton element" as the document node for 
xpath evaluation.

Best regards,
Erik

On 2009-12-21 14:24, Tyson, Paul H wrote:
> 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
>>>>
>>>>
>>>>
>>>>          
>>
>>