[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New working drafts posted
Hi Paul,
Ok. I think I prefer to not put in the EvaluateXpathAsNodes into the
XPathSelector. The behavior of the attribute selector changes in a
significant, but subtle and hard to understand manner because of this
attribute, so I think a completely different element is better.
Since we want to stabilize 3.0 now, let's leave that to a later date or
an additional profile in the next batch of documents.
Given this I think at least Paul and I have reached some kind of
consensus on the remaining issues. I'll post updated working drafts
before Christmas so everybody has something to read over the holidays. ;-)
Best regards,
Erik
On 2009-12-21 15:40, Tyson, Paul H wrote:
> OK, this is too difficult to work out for 3.0. I don't use this
> feature, so I don't have a wide range of realistic use cases. But from
> my experience with xslt and schematron, this will be a significant
> limitation for people who want to write complex rules around their XML
> content.
>
> A quick fix, as suggested by Erik, would be to add a boolean xml
> attribute like "EvaluateXpathAsNodes", which the implementation could
> use to make the correct API call. But this puts an extra burden on the
> policy-writer, which I am not sure is necessary, and would introduce an
> additional potential source of conflicting directives. So we should
> probably skip over this for now and consider it post-3.0.
>
> I suggest revising the opening paragraph of section 5.30 to something
> like:
>
> =======================
> The<AttributeSelector> element SHALL evaluate to a bag of values whose
> data-type is specified by the element's DataType attribute. The values
> shall be constructed from the node(s) selected by applying the xpath
> expression given by the element's Path attribute to the XML content
> indicated by the element's Category attribute, as described below.
> =======================
>
> Under the description of AttributeSelector/@Path, it should state that
> the xpath expression must evaluate to a nodeset. The statement, "There
> SHALL be no restriction on the Xpath syntax.", should be replaced with
> "The xpath expression SHALL conform to the declared XPathVersion
> syntax.".
>
> Regards,
> --Paul
>
>
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Saturday, December 19, 2009 05:39
>> To: Tyson, Paul H
>> Cc: xacml
>> Subject: Re: [xacml] New working drafts posted
>>
>> Paul,
>>
>> I am not convinced yet. :-)
>>
>> XACML 2.0 has a specification which says that the xpath
>> selects text content, which is then constructed into an XACML
>> data type.
>>
>> What you instead propose is that an XPath can select any
>> XPath data type, and the return value of the xpath is
>> directly the XACML value.
>>
>> I see value for both approaches, but we cannot mix them in
>> the same construct. This is what my code sample says. The
>> same XPath gives two different XACML datatype end results
>> depending which approach we use for the definition. We cannot
>> mix them (at least not for any given XACML data type).
>>
>> So this opens up the question about replacing the XACML 2.0
>> approach entirely with Paul's new proposal. It has the
>> benefit that more clever things can be done with the xpath expression.
>>
>> However, Paul's approach has the problem that not all XACML
>> data types are available in XPath, or at least not in XPath
>> 1. And definitely not in XPath 2 either if we consider that
>> XACML is extensible so users could define arbitrary data
>> types on their own. So to handle all XACML data types,
>> including extensions, we need the "select string content"
>> approach from XACML 2.0.
>>
>> Another benefit with the old selector approach is that it
>> easily handles selection of bags of attributes from the XML.
>> I don't know how that would work in Paul's approach.
>>
>> So I think the conclusion should be that we introduce a
>> separate construct which is purely XPath based, which takes
>> the XPath return value directly as the value of the XACML
>> data type. For XPath 1 only string, boolean and integer will
>> be possible return values. For XPath 2 there will be many more.
>>
>> And then I think there is ambiguity in the XACML 2.0
>> attribute selector definition as well. It's not clear to me
>> what the "text representation"
>> of an element node would be. For intance<Foo>true</Foo>,
>> would the selector "peek" inside the element to get "true"?
>> That seems inconsistent, if we imagine a custom extension
>> data type type such as<Book><Author>Smith</Author><Title>A
>> story</Title></Book>, where the book on the whole is treated
>> a data type. There we would like to pass the entire<Book>
>> node to the data type constructor, not peek inside.
>>
>> Best regards,
>> Erik
>>
>> P.S. My original email did not reach the list because of the
>> broken roster yesterday, but Paul quoted it from his CC so
>> you can find it below.
>>
>>
>>
>> On 12/18/2009 04:25 PM, Tyson, Paul H wrote:
>>
>>> Thanks for the code samples, Erik.
>>>
>>> As far as I can tell, the problem is limited to casting from text to
>>> boolean values. I encountered this problem repeatedly in xslt 1.0
>>> processing, but I never determined whether the defect was in the
>>> specification or the implementations. The problem has
>>>
>> disappeared in
>>
>>> xslt 2.0.
>>>
>>> The Java 5 xpath api is based on xpath 1.0, so it is not
>>>
>> surprising to
>>
>>> see this problem there as well.
>>>
>>> However, this is not a severe limitation. It only causes
>>>
>> ambiguity in
>>
>>> the case where you want to distinguish between "does this
>>>
>> node exist?"
>>
>>> and "does this node have a lexical value corresponding to
>>>
>> 'true' for the
>>
>>> xsd:boolean datatype?" The workaround requires the policy author to
>>> write xpath expressions that test the node value against
>>>
>> the expected
>>
>>> lexical values (e.g. "true","1", "yes", "false","0", "no") using the
>>> string equality operator.
>>>
>>> I modified Erik's sample to test numeric values, and it successfully
>>> evaluated "/ns:Foo/ns:Bar" with a numeric return value for
>>> "<ns:Bar>1</ns:Bar>".
>>>
>>> Therefore, I still believe we should allow any type of
>>>
>> xpath expression
>>
>>> in AttributeSelector/@Path, and specify that the result
>>>
>> must be returned
>>
>>> to the XACML environment as @DataType. The rules for converting
>>> datatypes from xpath to XACML are well-defined. Aside from the
>>> text-to-boolean problem noted above, this will in general
>>>
>> be a useful
>>
>>> and reliable way of testing XML content and structure.
>>>
>>> Regards,
>>> --Paul
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>>>> Sent: Friday, December 18, 2009 03:41
>>>> To: Tyson, Paul H
>>>> Cc: xacml
>>>> Subject: Re: [xacml] New working drafts posted
>>>>
>>>> Paul, All,
>>>>
>>>> I wrote a small test program, and it is as I feared it would
>>>> be. There is a fundamental ambiguity between the modes
>>>>
>>>> 1. The XACML 2.0 model: "select text content and construct a
>>>> data type value from the text"
>>>>
>>>> 2. The model proposed by Paul: "evaluate an xpath and convert
>>>> the xpath return value data type into an xacml data type"
>>>>
>>>> These two cannot be combined in the same construct (the attribute
>>>> selector) without some extra XML attribute which
>>>> differentiates between them. If we want both, I propose we
>>>> separate them into say<AttributeSelector> for the first and
>>>> <XPathExpression> for the latter.
>>>>
>>>> The fundamental problem is that in the xpath world, an xpath
>>>> which matches a text node counts as "true", if seen as a
>>>> boolean, while XACML wants to look inside the text node to
>>>> see the value of the string content.
>>>>
>>>> Here is the java test program I wrote:
>>>>
>>>> package com.axiomatics.xpathtest;
>>>>
>>>> import java.io.StringReader;
>>>> import java.util.HashSet;
>>>> import java.util.Iterator;
>>>> import java.util.Set;
>>>>
>>>> import javax.xml.XMLConstants;
>>>> import javax.xml.namespace.NamespaceContext;
>>>> import javax.xml.parsers.DocumentBuilder;
>>>> import javax.xml.parsers.DocumentBuilderFactory;
>>>> import javax.xml.xpath.XPath;
>>>> import javax.xml.xpath.XPathConstants;
>>>> import javax.xml.xpath.XPathExpression;
>>>> import javax.xml.xpath.XPathFactory;
>>>>
>>>> import org.w3c.dom.Document;
>>>> import org.w3c.dom.NodeList;
>>>> import org.xml.sax.InputSource;
>>>>
>>>> public class Main2 {
>>>>
>>>> static private class TestNamespaceContext implements
>>>> NamespaceContext {
>>>>
>>>> static private final String myns = "http://example.com";;
>>>> static private final String mypfx = "ns";
>>>>
>>>> @Override
>>>> public String getNamespaceURI(String prefix) {
>>>> if(prefix.equals(mypfx)) {
>>>> return myns;
>>>> } if(prefix.equals(XMLConstants.XML_NS_PREFIX)) {
>>>> } else {
>>>> return XMLConstants.XML_NS_URI;
>>>> } if(prefix.equals(XMLConstants.XMLNS_ATTRIBUTE)) {
>>>> return XMLConstants.XMLNS_ATTRIBUTE_NS_URI;
>>>> } else {
>>>> return XMLConstants.NULL_NS_URI;
>>>> }
>>>> }
>>>>
>>>> @Override
>>>> public String getPrefix(String namespaceURI) {
>>>> if(namespaceURI.equals(XMLConstants.XML_NS_URI)) {
>>>> return XMLConstants.XML_NS_PREFIX;
>>>> } else
>>>> if(namespaceURI.equals(XMLConstants.XMLNS_ATTRIBUTE_NS_URI)) {
>>>> return XMLConstants.XMLNS_ATTRIBUTE;
>>>> } else if(namespaceURI.equals(myns)) {
>>>> return mypfx;
>>>> } else {
>>>> return null;
>>>> }
>>>> }
>>>>
>>>> @Override
>>>> public Iterator getPrefixes(String namespaceURI) {
>>>> if(namespaceURI.equals(XMLConstants.XML_NS_URI)) {
>>>> Set result = new HashSet();
>>>> result.add(XMLConstants.XML_NS_PREFIX);
>>>> return result.iterator();
>>>> } else
>>>> if(namespaceURI.equals(XMLConstants.XMLNS_ATTRIBUTE_NS_URI)) {
>>>> Set result = new HashSet();
>>>> result.add(XMLConstants.XMLNS_ATTRIBUTE);
>>>> return result.iterator();
>>>> } else if(namespaceURI.equals(myns)) {
>>>> Set result = new HashSet();
>>>> result.add(mypfx);
>>>> return result.iterator();
>>>> } else {
>>>> Set result = new HashSet();
>>>> return result.iterator();
>>>> }
>>>> }
>>>> }
>>>>
>>>> private static final String xmlText =
>>>> "<ns:Foo xmlns:ns=\"http://example.com\";>\n" +
>>>> "<ns:Bar>false</ns:Bar>\n" +
>>>> "</ns:Foo>\n";
>>>>
>>>> static public void main(String[] args) throws Exception {
>>>> DocumentBuilderFactory dbfact =
>>>> DocumentBuilderFactory.newInstance();
>>>> dbfact.setNamespaceAware(true);
>>>> DocumentBuilder db = dbfact.newDocumentBuilder();
>>>>
>>>> Document indoc = db.parse(new InputSource(new
>>>> StringReader(xmlText)));
>>>>
>>>> // According to XACML 2.0 spec this if requested for
>>>> an XACML boolean
>>>> // should return "false" since it selects text
>>>> content with the string "false".
>>>> String xpathStr = "/ns:Foo/ns:Bar/text()";
>>>>
>>>> // compile the expression
>>>> XPathFactory factory = XPathFactory.newInstance();
>>>> XPath xpath = factory.newXPath();
>>>> xpath.setNamespaceContext(new TestNamespaceContext());
>>>> XPathExpression xPathEx = xpath.compile(xpathStr);
>>>>
>>>> // Match it as a nodeset. An XACML 2.0 implementation
>>>> // would take the text content and construct a
>>>> // an XACML boolean from the text value.
>>>> NodeList nodelist = (NodeList)
>>>> xPathEx.evaluate(indoc.getDocumentElement(),
>>>> XPathConstants.NODESET);
>>>> System.out.println("Matching nodes are: ");
>>>> for(int i = 0; i< nodelist.getLength(); i++) {
>>>> System.out.println(" -> " +
>>>> nodelist.item(i).toString());
>>>> }
>>>>
>>>> // Try to get the value directly using the same
>>>>
>> data type as
>>
>>>> // the attribute selector data type, that is, a boolean.
>>>> // This will return "true", which is different
>>>>
>> from above.
>>
>>>> Boolean bool = (Boolean) xPathEx.evaluate(indoc,
>>>> XPathConstants.BOOLEAN);
>>>> System.out.println("Return value is: " + bool);
>>>> }
>>>> }
>>>>
>>>> Best regards,
>>>> Erik
>>>>
>>>>
>>>>
>>>> On 2009-12-17 20:22, Erik Rissanen wrote:
>>>>
>>>>
>>>>> See inline,
>>>>>
>>>>> On 12/17/2009 06:55 PM, Tyson, Paul H wrote:
>>>>>
>>>>>
>>>>>>>> 2. Lines 2458/2461 unnecessarily restrict the @Path xpath
>>>>>>>>
>>>>>>>>
>>>>>>> expressions
>>>>>>>
>>>>>>>
>>>>>>>> to those that select nodes from an XML document. It
>>>>>>>>
>>>>>>>>
>>>> would exclude
>>>>
>>>>
>>>>>>>> node comparisons, counting, positional queries, and
>>>>>>>>
>> other useful
>>
>>>>>>>> expressions for testing XML structure. Erik thought
>>>>>>>>
>>>>>>>>
>>>> this would be
>>>>
>>>>
>>>>>>>> difficult to implement because of ambiguous return types
>>>>>>>>
>>>>>>>>
>>>> from these
>>>>
>>>>
>>>>>>>> expressions, but in fact they will be better-defined than
>>>>>>>>
>>>>>>>>
>>>>>>> XML nodes,
>>>>>>>
>>>>>>>
>>>>>>>> which will appear as string values when put into the XACML
>>>>>>>>
>>>>>>>>
>>>>>>> context.
>>>>>>>
>>>>>>>
>>>>>>>> The @DataType attribute of AttributeSelector will control
>>>>>>>>
>>>>>>>>
>>>>>>> the return
>>>>>>>
>>>>>>>
>>>>>>>> type to the XACML context, and if this type cannot be
>>>>>>>>
>>>>>>>>
>>>>>>> constructed from
>>>>>>>
>>>>>>>
>>>>>>>> the return value of the xpath expression the application
>>>>>>>>
>>>>>>>>
>>>>>>> must signal
>>>>>>>
>>>>>>>
>>>>>>>> an error. But this will not be the common case, and
>>>>>>>>
>>>>>>>>
>>>> when it does
>>>>
>>>>
>>>>>>>> arise the policy author can adjust the xpath expression
>>>>>>>>
>>>>>>>>
>>>> to cast the
>>>>
>>>>
>>>>>>>> value to a suitable argument type for the constructor
>>>>>>>>
>>>>>>>>
>>>>>>> function. As I
>>>>>>>
>>>>>>>
>>>>>>>> suggested earlier, this paragraph should be replaced with:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I tried to explain earlier that it is not as simple as that the
>>>>>>> @Datatype of the attribute selector can control this.
>>>>>>> Let's assume that I implement the selector with the Java
>>>>>>>
>>>>>>>
>>>> XPath API.
>>>>
>>>>
>>>>>>> The method for evaluating an xpath looks like this:
>>>>>>>
>>>>>>> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPathE
>>>>>>> xpression.html#evaluate%28org.xml.sax.InputSource,%20javax.xml
>>>>>>>
>>>>>>>
>>>>>> .namespace.QName%29
>>>>>>
>>>>>>
>>>>>>> Object evaluate(InputSource source, QName returnType)
>>>>>>> throws XPathExpressionException
>>>>>>>
>>>>>>> I have to specify the return type of the xpath expression when I
>>>>>>> evaluate it. This is not the same thing as the return
>>>>>>>
>> type of the
>>
>>>>>>> attribute selector, which the @Datatype denotes.
>>>>>>>
>>>>>>>
>>>>>> There is also an evaluate() method without the return
>>>>>>
>> type, so the
>>
>>>>>> client application could sort out the datatype if it wanted to.
>>>>>>
>>>>>>
>>>>> Do you refer to
>>>>>
>>>>> String evaluate(InputSource source)
>>>>>
>>>>> This is just a shorthand for evaluate(source,
>>>>>
>> XPathConstants.STRING)
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Consider this example:
>>>>>>>
>>>>>>> <Content>
>>>>>>> <Foo>true<Foo>
>>>>>>> </Content>
>>>>>>>
>>>>>>> <AttributeSelector Datatype="...boolean" Path="Foo/text()">
>>>>>>>
>>>>>>> then the xpath expression will evaluate to the string
>>>>>>>
>>>>>>>
>>>> "true", which
>>>>
>>>>
>>>>>>> according to the XACML spec has to be cast into an XACML
>>>>>>>
>>>>>>>
>>>> boolean. I
>>>>
>>>>
>>>>>>> must invoke the xpath evaluation with:
>>>>>>>
>>>>>>> evaluate(source, XPathConstants.STRING)
>>>>>>>
>>>>>>>
>>>>>> The question is, does the the xpath implementation try
>>>>>>
>> to cast the
>>
>>>>>> results to the desired type? I would assume so, in
>>>>>>
>> which case you
>>
>>>>>> can use the AttributeSelector/@DataType as the return type.
>>>>>>
>>>>>>
>>>>> Yes, maybe so. When I re-read it now, it appears so. The
>>>>>
>>>>>
>>>> first time I
>>>>
>>>>
>>>>> read it, I had the impression that this was not the case.
>>>>>
>>>>>
>>>> I'll try it
>>>>
>>>>
>>>>> out later.
>>>>>
>>>>>
>>>>>
>>>>>>> However, look at this:
>>>>>>>
>>>>>>> <AttributeSelector Datatype="...boolean"
>>>>>>>
>>>>>>>
>>>> Path="self::node() = Foo">
>>>>
>>>>
>>>>>>> In this case the data type of the selector is still an
>>>>>>>
>>>>>>>
>>>> XACML boolean.
>>>>
>>>>
>>>>>>> The difference is that the xpath expression returns an XPath
>>>>>>> boolean, which means I have to evaluate it with:
>>>>>>>
>>>>>>> evaluate(source, XPathConstants.BOOLEAN)
>>>>>>>
>>>>>>> If the implementation uses the wrong form, the XPath API
>>>>>>>
>>>>>>>
>>>> will throw
>>>>
>>>>
>>>>>>> an exception.
>>>>>>>
>>>>>>>
>>>>>> The XACML application cannot go wrong by using the
>>>>>>
>> @DataType value
>>
>>>>>> everywhere.
>>>>>>
>>>>>>
>>>>> Maybe. I need to check this, but now that I read the API
>>>>>
>>>>>
>>>> once more, I
>>>>
>>>>
>>>>> think you are right. Though, we can't use the @Datatyp
>>>>>
>>>>>
>>>> directly since
>>>>
>>>>
>>>>> XACML has more data types than XPath (at least XPath 1). And XACML
>>>>> uses URIs, which need to be converted to QNames. Anyway,
>>>>>
>>>>>
>>>> that should
>>>>
>>>>
>>>>> be workable.
>>>>>
>>>>>
>>>>>
>>>>>>> I don't know whether we should consider this a flaw in the java
>>>>>>> XPath API, or a more fundamental type checking issue, but
>>>>>>>
>>>>>>>
>>>> in either
>>>>
>>>>
>>>>>>> case it is a practical difficulty for implementation. We
>>>>>>>
>>>>>>>
>>>> could add a
>>>>
>>>>
>>>>>>> @PathReturnType attribute to the selector, and then the
>>>>>>> implementation would know. Any other suggestion?
>>>>>>>
>>>>>>>
>>>>>> I'm not in favor of an additional attribute. If the
>>>>>>
>>>>>>
>>>> underlying xpath
>>>>
>>>>
>>>>>> api or implementation has problems, then it will throw nuisance
>>>>>> errors and will perhaps be unusable. But that should not
>>>>>>
>>>>>>
>>>> affect or
>>>>
>>>>
>>>>>> restrict how we write XACML policies and make XACML requests.
>>>>>>
>>>>>> The bigger problem might be how to get a sequence of
>>>>>>
>>>>>>
>>>> values, without
>>>>
>>>>
>>>>>> knowing in advance whether an xpath expression will return one or
>>>>>> several values. The most useful API would always return a
>>>>>>
>>>>>>
>>>> sequence
>>>>
>>>>
>>>>>> from evaluate().
>>>>>>
>>>>>>
>>>>> This could be a problem with the java xpath API. It differentiates
>>>>> between NODE and NODESET as return types, but with some
>>>>>
>>>>>
>>>> luck one can
>>>>
>>>>
>>>>> always use NODESET and get a singleton set in case there is
>>>>>
>>>>>
>>>> a single
>>>>
>>>>
>>>>> node.
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> === proposed wd14 lines 2458/2461 === If the XPath expression
>>>>>>>> selects a sequence of XML nodes (text, attribute, element,
>>>>>>>> processing instruction, or comment nodes), then the string
>>>>>>>> representation of the value of each node MUST be
>>>>>>>>
>>>>>>>>
>>>>>>> converted
>>>>>>>
>>>>>>>
>>>>>>>> to an attribute value of the specified data-type, and
>>>>>>>>
>>>>>>>>
>>>> the result of
>>>>
>>>>
>>>>>>>> the AttributeSelector is the bag of the attribute values
>>>>>>>>
>>>>>>>>
>>>> generated
>>>>
>>>>
>>>>>>>> from all the selected nodes.
>>>>>>>> =====================================
>>>>>>>>
>>>>>>>> 3. Lines 2466/2469 regarding the definition of the XML
>>>>>>>>
>>>>>>>>
>>>>>>> infoset that is
>>>>>>>
>>>>>>>
>>>>>>>> subject to xpath processing: The xacml:Content
>>>>>>>>
>> element does not
>>
>>>>>>>> belong in this infoset. The XML that is subject to xpath
>>>>>>>>
>>>>>>>>
>>>>>>> evaluation
>>>>>>>
>>>>>>>
>>>>>>>> should be the sequence of nodes that are the children of the
>>>>>>>> xacml:Content element. This can include zero or more elements,
>>>>>>>> comments, processing instructions, and text nodes. I propose
>>>>>>>> replacing the first sentence of this paragraph with:
>>>>>>>>
>>>>>>>> === proposed wd14 lines 2466/2467 === The Xpath
>>>>>>>>
>>>>>>>>
>>>> expression MUST be
>>>>
>>>>
>>>>>>>> evaluated in a context which is equivalent to a node sequence
>>>>>>>> formed of all the child nodes of the<Content> element,
>>>>>>>>
>>>>>>>>
>>>> and all the
>>>>
>>>>
>>>>>>>> attributes and
>>>>>>>>
>>>>>>>>
>>>>>>> descendants of those nodes.
>>>>>>>
>>>>>>>
>>>>>>>> Namespace declarations ... [unchanged]
>>>>>>>> ======================================
>>>>>>>>
>>>>>>>> Note that this makes user-defined attributes of xacml:Content
>>>>>>>> invisible to xpath expressions, so we should consider removing
>>>>>>>> "anyAttribute" from the schema definition of xacml:Content.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I think we want the<Content> element since otherwise
>>>>>>>
>>>>>>>
>>>> it's not going
>>>>
>>>>
>>>>>>> to be a valid stand alone XML document. (XML requires a single
>>>>>>> document element, righ?) If there is not a single
>>>>>>>
>>>>>>>
>>>> document element,
>>>>
>>>>
>>>>>>> the aboslute xpath "/" becomes undefined. There is no
>>>>>>>
>> harm having
>>
>>>>>>> the content element there.
>>>>>>> In fact, it could even be beneficial to use the XML
>>>>>>>
>> attributes of
>>
>>>>>>> the<Content> element since XML attributes have a slightly more
>>>>>>> compact encoding form than elements (which repeat the
>>>>>>>
>> name of the
>>
>>>>>>> element at the end tag).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> I think that xacml:Content belongs in the XACML world, and its
>>>>>> children belong in the user's world. The<Content> element is a
>>>>>> wrapper that should not be visible or accessible during
>>>>>>
>>>>>>
>>>> policy evaluation.
>>>>
>>>>
>>>>>> We should define this in terms of the xpath data model
>>>>>>
>>>>>>
>>>> (XDM) instance
>>>>
>>>>
>>>>>> that will be created from xacml:Content, which will be the
>>>>>>
>>>>>>
>>>> subject of
>>>>
>>>>
>>>>>> any xpath expression evaluations. The "sequence of nodes" I
>>>>>> originally proposed will not work. I propose the model be
>>>>>>
>>>>>>
>>>> specified as:
>>>>
>>>>
>>>>>> 1. A new document node will be created for each<Content>
>>>>>>
>> element.
>>
>>>>>> 2. All xml content of the xacml:Content element will be
>>>>>>
>> parsed and
>>
>>>>>> put into the xpath data model as specified by the xpath
>>>>>>
>> data model
>>
>>>>>> specification (http://www.w3.org/TR/xpath-datamodel).
>>>>>>
>>>>>> (This is a notional specification only--there is no
>>>>>>
>>>>>>
>>>> requirement that
>>>>
>>>>
>>>>>> the implementation actually do this--only that the results
>>>>>>
>>>>>>
>>>> of xpath
>>>>
>>>>
>>>>>> evaluation are the same as if this had been done.)
>>>>>>
>>>>>> Note that this could result in a valid XDM structure
>>>>>>
>> that would be
>>
>>>>>> malformed XML, because the document node could have
>>>>>>
>>>>>>
>>>> several element
>>>>
>>>>
>>>>>> children. (In an XDM constructed from valid XML, the
>>>>>>
>> document node
>>
>>>>>> would have only one element child--the document element.)
>>>>>>
>>>>>>
>>>> I do not
>>>>
>>>>
>>>>>> see anything that prohibits this, either in the XDM or the Xpath
>>>>>> specification.
>>>>>>
>>>>>>
>>>>> Yes, the content belongs to the XACML world, but I think it is
>>>>> perfectly fine as a place holder. A policy belongs to the
>>>>>
>>>>>
>>>> XACML world
>>>>
>>>>
>>>>> and having a content element as the starting point of expressions
>>>>> seems fine for me.
>>>>>
>>>>> I am not sure if I understand what you propose. The data
>>>>>
>>>>>
>>>> model is part
>>>>
>>>>
>>>>> of XPath 2.0. Will your approach work with 1.0?
>>>>>
>>>>> From my experience about using the java xpath API, it
>>>>>
>>>>>
>>>> requires a DOM
>>>>
>>>>
>>>>> and absolute xpaths don't work correctly if the document
>>>>>
>> element of
>>
>>>>> the DOM is not set. I see in the spec for the XPath data
>>>>>
>>>>>
>>>> model that a
>>>>
>>>>
>>>>> document node is not required to contain exactly one
>>>>>
>> element child,
>>
>>>>> but what would "/" resolve to in your approach?
>>>>>
>>>>> Best regards,
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]