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:
- 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.
- 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?
- 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.
- Paul's original point 3, which shifts the context node of the
AttributeSelector from the Content node, to its child or children nodes.
- 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:
- Why not leave things as is, where this problem of multiple
context nodes did not originally exist?
- If we leave things the way they are originally, do we really
want to allow multiple children of the Content node?
- 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.
- 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.
- 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