Re: [xacml] New working drafts posted

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Paul and Erik,

I have been trying to follow this discussion, but the details have gotten a little too detailed and, at least for me, are obscuring the "big picture". So, let me first say what I think the discussion is about, then offer my two cents.

It sounds like there are two main points, which are pretty much independent of each other:

1. Paul's original point 2, saying lines 2458-2461, which is carried over from XACML 2.0 to 3.0 unchanged is too restrictive, because it only allows an AttributeSelector to return a bag of attribute values, and that it should be allowed to return other things that XPath expressions can produce.
1. My first reaction is what other things can these expressions produce? And how would they be used, for example, in complex expressions like that in example 2, Rule 1, section 4.2.4.1 where an AttributeDesignator is compared with an AttributeSelector? Does this not put an imbalance there?
2. If my first point is accurate, then I think this change would be destabilizing, and we should drop it until a later time when it can be considered in more detail on its merits.
2. Paul's original point 3, which shifts the context node of the AttributeSelector from the Content node, to its child or children nodes.
1. My first reaction here is that we are suddenly going from one context node to possibly many context nodes. I also see that this discussion led to the point in the current email, where a single child restriction is being recommended for the Content node. This brings up 2 questions in my mind:
1. Why not leave things as is, where this problem of multiple context nodes did not originally exist?
2. If we leave things the way they are originally, do we really want to allow multiple children of the Content node?
2. If my reading above is correct, and multiple context nodes are a problem, then I would suggest going along w Paul's most recent suggestion and only allow one child of the Content node, which possibly can be done by removing maxOccurs="unbounded" from the defn of the Content element.
3. Possibly related to this overall concern is that my understanding of the new attribute, ContextSelectorId, is that it provides an alternative "context node" somewhere else within the Content node, i.e. some descendant. i.e. it "overrides" the Content node as being the root, if you will, of the expression in the renamed Path attribute. Clearly, there is no control over how many children this new context node can have, so if that is not a concern, then why would it be a concern for the original Content node? Or is it a concern for both? i.e. this is the type of thing that is making this discussion hard for me to follow.
   
4. Also, I agree w Paul that the Content node probably does not need the "anyAttribute", unless possibly there is some technical need to put namespace context attributes here or something of that sort.

Bottom line: my interest here is that we don't do things that destabilize the spec at this late time, and based on my reading and interpretation above, I am getting concerned that we are getting into some tricky issues that could probably be avoided by leaving things alone unless something is really broken.

    Thanks,  
    Rich

Tyson, Paul H wrote:

3898C40CCD069D4F91FCD69C9EFBF0960423FDBB@txamashur004.ent.textron.com" type="cite">

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


    

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php