I just installed Saxonc Python API. All the examples work fine. However, every time I try to evaluate my own expressions, the XPath processor returns an empty sequence. I tested the expressions using Oxygen, and it works well and selects the right node under Xpath 2.0. I think the issue may be that by default, the Xpath processor uses Xpath version 1.0.
Saxonc Python API documentation says that:
Saxon/C provides processing in XSLT 3.0, XQuery 3.0/3.1 and XPath 2.0/3.0/3.1, and Schema validation 1.0/1.1.
However, I can't find how to change the Xpath version.
Related
I am trying to use Regular expression extractor to extract, but i don't know how to use it here. Since the "request number" is visible only in "Response Data" of "View result tree". where should i place the post processor. what would be my regular expression.
edit: I have added my regular expression and result screen
Your response value is a number, without double quotes, so change your Regular expression to
"response":(\d+)
Parsing JSON data using regular expressions is not the best idea, I believe you should be using JSON Extractor instead.
It's available since JMeter version 3.0 and you should be able to use it instead of the Regular Expression Extractor.
The relevant JsonPath query will be as simple as:
$.response
Full configuration just in case:
Also be aware that according to JMeter Best Practices you should always be using the latest version of JMeter so consider migrating to JMeter 5.0 (or whatever is the latest version available at JMeter Downloads page) on next available opportunity.
I am looking for standard ways to arrive at complex xpath expressions in protractor.
For e.g. I have a complex xpath as follows:
(//*[contains(#class,'day')][normalize-space(text())='2'])[1]
Here I have to get first access to elements matching xpath
//*[contains(#class,'day')][normalize-space(text())='2']
and then pick the first from the matching ones. Any pointers?
Protractor in its documentation clearly describes any process for creating xpaths:
http://www.protractortest.org/#/style-guide [section Locator strategies].
Firstly, you shouldn't use XPath except as a last resort. I second the recommendation by #Kacper to read the style guide he posted.
However, if you're dead set on using XPath, (sometimes it is unavoidable), you can pick the first element that matches like so:
element.all(by.xpath("//*[contains(#class,'day')][normalize-space(text())='2']")).first();
Issue:
When using [name() = "SomeValue"] in Edge, it will not return nodes if the "SomeValue" to match contains capital letters. Even if those capital letters match the node name exactly.
Example:
I have created this JSFiddle which exhibits problem. It uses two XML strings, both a subset of the books.xml sample on MSDN, where the first has capitalized node names and the second I have modified to use lowercase node names. Fiddle with cleaner code.
Current Results:
Running the fiddle in Edge, you will see when searching for [name() = "catalog"] where "catalog" is in any mixed case, the XPath will match nodes only when the search term is fully lowercase. Notice that it doesn't matter what the case of the matching node is, the term "catalog" will match a node if the node name is camel case, full caps, or all lowercase.
Edge will match all three of these nodes:
<Catalog/>
<CATALOG/>
<catalog/>
When running the same in another browser (I have tested Firefox, Chrome, and Opera), the search term must match the node name case exactly, and is how I would expect XPath to operate. Out of the three node names above these browsers will only match <Catalog/> when using [name() = "Catalog"]
Expected Results:
I would expect Edge to behave the same as other browsers, since other functions like text() don't operate this way in Edge, which makes it even more inconsistent. This is shown in the JSFiddle as well.
Another reason I expect the same behavior, is that only XPath 1.0 is supported for all my tested browsers, so there should be no difference there.
In summary:
Is this a defect in Edge? / Is this allowed by the standard? If it is not allowed, I can write up a bug report to Microsoft. If it is allowed by the standard, do I just need to account for the browser difference?
Additional Info
Supporting existing software using jQuery, and looking for a solution which does not require additional third party software.
XPath 1.0 is defined over a particular data model, which is not exactly the same as the HTML DOM. And the HTML5 DOM in particular was defined many years after XPath 1.0 was frozen. This means that anyone implementing XPath 1.0 over the HTML5 DOM has to decide how to map the HTML5 DOM to the XPath data model. It's very unfortunate if different vendors do this mapping in different ways, but it's not actually a violation of any standard. One of the key decisions to make in defining this mapping is how to cope with the fact that HTML5 is case-insensitive while XPath 1.0 is case-sensitive.
The underlying problem here is that you are using the HTML5 DOM to hold stuff that isn't HTML. This is a bad idea, because HTML5 tries hard to bend your content to the HTML5 model, which may corrupt your data in surprising ways. It would be much better to create an XML DOM for this data.
Also, using the predicate [name()='SomeValue'] is bad practice anyway, because XPath 1.0 gives no guarantees about namespace prefixes in the result of the name() function. It's much better to use self::SomeValue, or self::hh:SomeValue if the data is in a namespace (although the mapping of HTML5 to a namespaced instance of the XPath data model raises another set of potential issues.)
Suggestion: use Saxon-JS as your XPath engine. That way (a) you get support for XPath 3.0 rather than 1.0, and (b) you're using the same XPath engine on every browser, so it will give compatible behaviour across browsers.
I am trying to search under 2 different nodes for a specific name. This works
/jcr:root/db067409/libraries/bd0b868d/_x0030_//*[#name="FIRST"]
But when I try to OR it with the second node like so...
/jcr:root/db067409/libraries/bd0b868d/_x0030_//*[#name="FIRST"]|/jcr:root/db067409/libraries/_x0033_78d57e4/_x0031_//*[#name="FIRST"]
I no longer get any search results. Please could someone point out what I've done wrong.
What I'd really like to do is along these lines; if I have /a/b/ID1/VERSION1 and /a/b/ID2/VERSION2 I'd like an xpath something like this /a/b/(ID1/VERSION1 or ID2/VERSION2)//*[#name="some name"].
Answer is no. Unfortunately, it doesnt throw an UnsupportedOperationException like you'd expect. There was an item in Jira but I guess they ignored it as Xpath is now deprecated.
Use JCR_SQL2 if you do need a union.
Edit
This thread indicates that a union-like feature is available in Jackrabbit 2.0, but not earlier.
[Joins] are not possible with JCR
Xpath or JCR-SQL, but with the new query model in JCR 2.0 (JCR-SQL2).
This is supported since CQ 5.3 / CRX 2.0 / Jackrabbit 2.0. Please note
that these joins aren't optimized very much.
Indeed, XPath is deprecated in JCR 2.0.
JCR 1.0 defines a dialect of SQL different from JCR-SQL2, as well as a dialect of XPath. Support for these languages is deprecated.
I'm updating codes to use MSXML6.0 from MSXML3.0.
However, I noticed that, for MSXML3.0, the default "SelectionLanguage" is "XSL Pattern", while MSXML6.0 only support XPath.
I have concerns that this change would introduce differences in the query syntax.
Can somebody list the difference of syntax between these two syntax?
The one thing that has tripped me up is selecting the first node in a node set. For example, we'd been using MSXML 3.0 (which uses XSLPattern) and has queries like this:
/root/book[0]
This query was supposed to select the first book. This works with XSLPattern. But with XPath, this is correct:
/root/book[1]
So when I switched us to using MSXML 6.0, which uses correct XPath, all those queries with "[0]" stopped working.
Update:
I just found this link that talks some more about XSLPattern and XPath:
MSDN Magazine: MSXML 3.0 Supports XPath 1.0, XSLT 1.0, XDR, and SAX2
http://msdn.microsoft.com/en-us/magazine/cc302348.aspx
Update #2:
Here's the W3C Spec on XSLT which includes XSL Patterns:
http://www.w3.org/TR/1998/WD-xsl-19981216.html#AEN376
Update #3
Here's another post that describes the same thing I mentioned above:
http://www.eggheadcafe.com/software/aspnet/29579789/xml-parsing.aspx
XSL Pattern, if I remember correctly, was a selection language like XPath but was implemented by Microsoft before XPath was standardised (possibly even created). I don't think anyone even has anything that documents XSL Pattern any more. You can basically forget about it and concentrate on XPath. It has the same purpose but is supported and standardised.
XSL Patterns appear to be part of WD-XSL, "working draft XSL", which means versions predating the XSL recommendation (1999), which differ significantly from the final 1.0 version.
Microsoft has the relevant info on "XSL Patterns". Here's a quote from the section XPath 1.0 APIs:
MSXML 2.0 provides support for XSL Patterns, the precursor to XPath 1.0. The notion of an XML addressing language was introduced into the original W3C XSL Working Drafts (http://www.w3.org/TR/1998/WD-xsl-19981216.html) and called XSL Patterns. MSXML 2.0 implements the XSL Patterns language as described in the original XSL specification with a few minor exceptions.
MSXML 3.0 provides support for the legacy XSL Patterns syntax as well as XPath 1.0.
XPath, in my experience, is much easier to get your head around. I avoid XSL like the plague if I can. But you are right, the syntax is very different, so if you want to switch from XSL to XPath you have some work ahead of you. I cannot explain the differences easily, but this tutorial should give you some idea of what XPath is about:
http://www.w3schools.com/XPath/xpath_examples.asp