I am trying to understand what the XACML specs mean by how a <target> elements can be calculated from the <Target> elements of the <PolicySet>, <Policy> and <Rule> elements that it contains. Section 3.3.2.1 gives the following explanation:
...there are two logical methods that might be used. In one method, the <Target> element of the outer <PolicySet> or <Policy> (the "outer component") is calculated as the union of all the <Target> elements of the referenced <PolicySet>, <Policy> or <Rule> elements (the "inner components").
In another method, the <Target> element of the outer component is calculated as the intersection of all the <Target> elements of the inner components.
The results of evaluation in each case will be very different: in the first case, the <Target> element of the outer component makes it applicable to any decision request that matches the <Target> element of at least one inner component; in the second case, the <Target> element of the outer component makes it applicable only to decision requests that match the <Target> elements of every inner component.
I do understand why this is done, clearly to be able to select the proper Policy or PolictSet to evaluate, but I have no idea how this can be accomplished. I did look at Sun's XACML and AT&T XACML 3.0 implementations, but can't find any code samples to illustrate how this is done.
So, my question is, can somebody explain in detail how this calculation is to be done or refer to a (academic) paper or code that ahows this type of calculation? Did I miss something in the Sun and AT&T code base?
Related
This question already has answers here:
Why is XPath contains(text(),'substring') not working as expected?
(2 answers)
XPath contains(text(),'some string') doesn't work when used with node with more than one Text subnode
(7 answers)
Testing text() nodes vs string values in XPath
(1 answer)
Closed 3 months ago.
I want to clearly understand what is the difference between the following XPath expressions "//*[contains(.,'sometext')]" and "//*[contains(text(),'sometext')]".
From this great answer I understand, that text() returns a set of individual nodes, while . in a predicate evaluates to the string concatenation of all text nodes.
OK, but when I'm using [contains(.,'sometext')] or [contains(text(),'sometext')] this should return the same amount of elements matching those XPaths since here we checking for nodes containing someText content in itself or in some of their children. Right? And it doesn't matter if we are checking whether any of the text nodes of an element contains sometext or string concatenation of all text nodes contains the sometext text. This should give the same amount of matches.
However if we test this for example on this page I see 104 matches for //*[contains(text(),'selenium')] XPath while //*[contains(.,'selenium')] XPath is giving 442 matches.
So, what causes this difference?
Let me share my understanding using this xml.
<test>
<node>
selenium
<node2>
selenium
</node2>
</node>
<node>
selenium
</node>
</test>
First of all function text() returns list of node objects.
Function contains() takes two arguments where the first one is a string. So having this //*[contains(text(),'selenium')] would not always work. In XPath v2.0 It will fail when text() supplies several nodes to contains.
In my mentioned example white spaces before nodes are also text node:
This is why in my test your //*[contains(text(),'selenium')] query failed. Probably browsers have some work around for that to make things easier.
Now lets collapse that xml to get rid of that noise and look at the differences of approaches:
<test><node>selenium<node2>selenium</node2></node><node>selenium</node></test>
1. use text().
Here what https://www.freeformatter.com/xpath-tester.html returns:
Element='<node>selenium<node2>selenium</node2>
</node>'
Element='<node2>selenium</node2>'
Element='<node>selenium</node>'
Since //* defines all nodes within the tree here we have /test/node[1] that contains, also /test/node[1]/node2 and /test/node[2].
2. Now lets look at . case:
Now it returns:
Element='<test>
<node>selenium<node2>selenium</node2>
</node>
<node>selenium</node>
</test>'
Element='<node>selenium<node2>selenium</node2>
</node>'
Element='<node2>selenium</node2>'
Element='<node>selenium</node>'
Why? because first of all /test is converted to seleniumseleniumselenium. Then /test/node[1] is converted to seleniumselenium, then /test/node[1]/node2 is converted to selenium and finally /test/node[2] is converted to selenium
So this makes the difference. Depending on how complex your nesting is, the results might show more or less significant difference between to approaches.
This thread exlains the difference between dot and text() pretty well: XPath: difference between dot and text()
I have the following configuration for storing a field.
<fieldType fieldName="Profile Id" storageType="YES" indexType="TOKENIZED" vectorType="NO" boost="1f" type="System.Guid" nullValue="NULL" emptyString="EMPTY" settingType="Sitecore.ContentSearch.LuceneProvider.LuceneSearchFieldConfiguration, Sitecore.ContentSearch.LuceneProvider" />
When I check the index with LukeAll I see the id as:
I don't know why the curly braces are gone and why all the characters are in lowercase. I want to store it as normal guid like in sitecore with curly braces and all chars in uppercase.
I also tried with type="System.string" but its still the same.
Actually, because your field is TOKENIZED, Sitecore stores your ID the way it does to avoid another situation from happening. TOKENIZED means, your ID will be broken down internally in Lucene like this:
c50e5028
8eba
4ba9
854cf
(you get the picture)
So if you search Lucene for 8eba it will match your profile_id field as you see it now. Which is very rarely what one would expect.
To avoid this issue; don't put a Sitecore ID in the index. Not a Guid either. (there are other workarounds, but I'm showing you the simpler approach here).
Use item.ID.ToShortID() - this generates a Guid that is without curly braces and without dashes. When you later want to compare (or query), just match it up using the same .ToShortID() method.
To me it looks like your original value is not containing curly braces.
If the field value contains curly braces (and storageType="YES") Luke will show you the value that was indexed as apposed the index data (which may be very different based on analyzer used).
If you truly want the index data to contain curly braces either set indexType="UN_TOKENIZED" or choose something like the Lucene.Net.Analysis.WhitespaceAnalyzer for the field.
I'm using odoo 8 in my class I use a field selection but when I use it in the view XML with the widget statusbar the values are all in not order (all mess up) it is showing me the values in the statusbar first cancel, then new, then confirm all in disorder why is doing this?
this is my code in the class
'state': fields.selection ({('new','Nueva'),
('draft','Asignada'),
('cancel','Cancelada'),
('sent','Revisada'),
('confirmed','Atendiendose'),
('done','Liberada'),
('agent','Agendada')},
'Estatus Orden')
in the view xml i only worte this:
field name="state" widget="statusbar"
I don't know how to order correctly because the bar shows the list in not order does anybody know?
You can arrange the sequence of the state. You can add state to status bar in the following way
<field name="state" widget="statusbar" statusbar_visible="new,draft,confirmed,cancel" />
You need to replace {} in fields.selection by [].
Because there is huge difference between set {} and list [].
Set :
The sets module provides classes for constructing and manipulating unordered collections of unique elements. Common uses include membership testing, removing duplicates from a sequence, and computing standard math operations on sets such as intersection, union, difference, and symmetric difference.
Refer more about Set
List :
Lists are are really variable-length arrays, not Lisp-style linked lists. The list type is a container that holds a number of other objects, in a given order (Ordered Collection). The list type implements the sequence protocol, and also allows you to add and remove objects from the sequence.
Refer more about List
Field definition :
'state': fields.selection ([('new','Nueva'), ('draft','Asignada'), ('cancel','Cancelada'), ('sent','Revisada'), ('confirmed','Atendiendose'), ('done','Liberada'), ('agent','Agendada')], 'Estatus Orden')
Difference between Set and List
Sets and Lists in Python
In Python, when to use a Dictionary, List or Set?
What is the exact meaning of :: ?
And apart from parent, what else are the different things we can use?
By.xpath("parent::*/parent::*")
The shortest answer I can manage
:: separates an axis name from a node test in an XPath expression.
The longer answer
It does not make much sense to ask about the meaning of ":: in Selenium", because it's not a feature of Selenium. It belongs to XPath, which is a W3C specification in its own right and is used to navigate XML or XHTML documents.
By.xpath(" parent::*/parent::* ")
^ ^ ^
Selenium XPath Selenium
Selenium just happens to embed XPath in their web application framework (which is a good thing!).
So, I've taken the liberty to answer the question: What is the meaning of :: in XPath?
The meaning of :: in XPath
In XPath, :: does not mean anything on its own and only makes sense if there is
a valid XPath axis identifier to the left
a valid node test to the right
For example, parent::* is a valid XPath expression1. Here, parent is an XPath axis name, * is a node test2 - and :: marks the transition from the axis to the node test. Other possible axes are
ancestor following-sibling
ancestor-or-self namespace
attribute parent
child preceding
descendant preceding-sibling
descendant-or-self self
following
Of course those are not just names, they have a very clear-cut semantic dimension: each of them defines a unique way to navigate an XML document (or, rather, a tree-like representation of such a document). Their meaning is straightforward in most cases, for instance, following:: identifies something that "follows" the current context.
These tuples of axis and node test (or triples, also counting predicates) can be "chained together" with the binary / operator to form paths with several steps:
outermost-element/other/third
Navigating a simple document
<root>
<person>James Clark</person>
<person>Steve DeRose</person>
</root>
Naturally, navigation might depend very much on your current whereabouts. There are both absolute and relative path expressions. An example for an absolute path expression is
/child::root/child::person | abbreviated syntax: /root/person
As you can see, there is a / at the beginning of an absolute path expression. It stands for the document node (the outermost node of a tree, which is different from the outermost element node of a a tree). Relative path expressions look like
child::person | abbreviated syntax: person
The relative path expression will only find the person element node if the current context is the root element node. Otherwise, it will fail to locate anything.
Your XPath expression
To sum up and use what we have learned so far:
By.xpath("parent::*/parent::*")
finds the element node that is the grandparent of the current node. The names of both the parent and the grandparent node do not matter (that's what *is for). There's no / at the beginning, so it must be a relative path.
1 In fact, it is a location path, a special kind of XPath expression. Also, I have left out one important concept: predicates. Good things always come in threes, and XPath expressions come with an axis, a node test and with zero or more predicates.
2 A node test must be either a name test (testing the name of a node) or a kind test (testing the kind of node). Find ample information about node tests in the relevant part of the XPath specification.
This is xpath syntax, you can do other things like :
child::* Selects all element children of current node
attribute::* Selects all attributes of current node
child::text() Selects all text node children of current node
child::node() Selects all children of current node
Check a tutorial, especially about axes :
http://www.w3schools.com/xpath/xpath_axes.asp
I'm using an SRGS grammar to refine accuracy of a Microsoft Speech STT service.
I have specific needs for this grammar because I would like it to match some words by prefix only, but get the whole word as a result of detection.
This is the kind of rule I tried:
<rule id='test'>
<item>
contain<ruleref uri="grammar:dictation" type="application/srgs+xml"/>
</item>
</rule>
I would like this rule to match things like:
"contain", "contains", "containing"
Problem is the only things I get in vocal detection are like:
"contain and", "contain he"
This must be because I can't have both plain text ("contain") and the dictation tag defining a single word. STT assumes these will be 2 separate words and adapts the recognition result accordingly.
The ruleref tag referencing grammar:dictation is necessary in my case because if I use something like the "GARBAGE" special rule instead, I think I will not be able to fetch the whole word.
Any tips or ideas would be greatly appreciated, I'm afraid what I'm trying to do might be impossible in the current SRGS state.