I'm developing my own SPARQL parameterized query String. I want to inject values into the string using a specified convention.
I'm using a colon followed by a number to denote injectable values, e.g.,
Filter(?myVar = :1). Then I would search for ":" followed by a number and replace it. Only one restriction: no ttl based uris are allowed, so that the ":" won't mix with uris.
Apache Jena uses variables for injection (normal SPARQL variables that start with a question mark followed by a variable identifier) and dot net Rdf uses "#" followed by identifier.
Question
Do you see anything wrong with my approach of ":" followed by number? What should be considered to provide a method with minimal ambiguity or undesired behaviours?
Related
I am using Directory.GetDirectories() to get a list of folders that meet a certain criteria by using its searchPattern parameter.
I am only looking for any folders containing a specific word, say alphabet, my code is as follows:
Directory.GetDirectories(rootToSearch, "*alphabet*")
But, there is a common abbreviation that I know to expect for this word, say abc. If I was searching in Windows File Explorer I could search for *alphabet* OR *abc* and it would work as expected, however putting this as the searchPattern results in the function finding no folders, presumably because it is taking it as one search term including OR as a literal, instead of 2 terms delineated with OR.
Is there any way to achieve an OR statement in the search pattern? The MSDN says:
The search string to match against the names of subdirectories in path. This parameter can contain a combination of valid literal and wildcard characters, but it doesn't support regular expressions.
So I know that I can't use Regular Expressions. I tried using |, but that results in an Illegal characters in path error.
As per this question you can use LINQ to filter an array of all directories on the root, instead of using the searchPattern
But that question used GetFiles() and there are certain things to take into account when using the solution for GetDirectories()
To ensure that your search pattern is indeed being used only against the folder name rather than the entire path, use DirectoryInfo
LCase() is also used to mimic GetDirectories() accordingly.
Dim folders = Directory.GetDirectories(rootToSearch) _
.Where(Function(s)
Return LCase(New DirectoryInfo(s).Name).Contains("abc") Or LCase(New DirectoryInfo(s).Name).Contains("alphabet")
End Function)
I have review multiple instructions on URL-parameters which all suggest 2 approaches:
Parameters can follow / forward slashes or be specified by parameter name and then by parameter value. so either:
1) http://numbersapi.com/42
or
2) http://numbersapi.com/random?min=10&max=20
For the 2nd one, I provide parameter name and then parameter value by using the ?. I also provide multiple parameters using ampersand.
Now I have see the request below which works fine but does not fit into the rules above:
http://numbersapi.com/42?json
I understand that the requests sets 42 as a parameter but why is the ? not followed by the parameter name and just by the value. Also the ? seems to be used as an ampersand???
From Wikipedia:
Every HTTP URL conforms to the syntax of a generic URI. The URI generic syntax consists of a hierarchical sequence of five components:
URI = scheme:[//authority]path[?query][#fragment]
where the authority component divides into three subcomponents:
authority = [userinfo#]host[:port]
This is represented in a syntax diagram as:
As you can see, the ? ends the path part of the URL and starts the query part.
The query part is usually a &-separated string of name=value pairs, but it doesn't have to be, so json is a valid value for the query part.
Or, as the Wikipedia articles says it:
An optional query component preceded by a question mark (?), containing a query string of non-hierarchical data. Its syntax is not well defined, but by convention is most often a sequence of attribute–value pairs separated by a delimiter.
It is also fairly common for request processors to treat a name=value pair that is missing the = sign, as if the it was name=.
E.g. if you're writing Servlet code and call servletRequest.getParameter("json"), it would return an empty string ("") for that last URL in the question.
Let admit that with Jersey I expose 2 queries that are :
/hello/{name}
/hello/goodby
If the user do /hello/goodby, does Jersey guarantie that it is the request "/hello/goodby" that will be chosen and not "/hello/{name}" with the name equals to "goodby" ?
I have case like that in the services that I expose, it seems that static path is always chosen but I'm looking for a kind of confirmation in the documentation and I don't see anything here : https://jersey.github.io/documentation/latest/jaxrs-resources.html#d0e2271
It's not going to be in the documentation. It's going to be in the JAX-RS Spec. Look in the section "3.7.2 Request Matching", and somewhere along in the cryptic mumbo jumbo you will see this:
Sort E using the number of literal characters in each member as the primary key
E being the so far qualified methods based on path. This means that the path with the most literal characters should be prioritized. In your case, that's why /hello/goodbye always wins. goodbye are literal characters, while {name} has zero literal characters, it's a capture group.
That is correct. /hello/goodby is given precedence over /hello/{name} assuming both are at the same level like class or method.
All matching classes are sorted in descending order on the below conditions -
Number of literal characters as primary key
Number of path params as secondary key
Number of regex strings as ternary key.
In your case, you have only literal characters and path params.
/hello/goodby - 12 literal characters and 0 path params.
/hello/{name} - 4 literal characters and 1 path params.
According to the sorting algorithm, /hello/goodby will be before /hello/{name}, and /hello/goodby is the best match.
This question already has answers here:
Is there any language that allows spaces in its variable names [closed]
(2 answers)
Closed 9 years ago.
Related: Why can't variable names start with numbers?
Is there a technical reason why spaces aren't allowed in variable names or is it down to convention?
For example, what's stopping us from doing something like this?:
average score = sum of scores / number of scores
The only issue that comes to mind is keywords, but one could simply restrict the use of them in a variable name, and the lexer would be able to distinguish between part of a variable and a keyword.
There’s no fundamental reason, apart from the decisions of language designers and a history of single-token identifiers. Some languages in fact do allow multi-token identifiers: MultiMedia Fusion’s expression language, some Mac spreadsheet/notebook software whose name escapes me, and I’m sure of others. There are several considerations that make the problem nontrivial, though.
Presuming the language is free-form, you need a canonical representation, so that an identifier like account name is treated the same regardless of whitespace. A compiler would probably need to use some mangling convention to please a linker. Then you have to consider the effect of that on foreign exports—why C++ has the extern "C" linkage specifier to disable mangling.
Keywords are an issue, as you have seen. Most C-family languages have a lexical class of keywords distinct from identifiers, which are not context-sensitive. You cannot name a variable class in C++. This can be solved by disallowing keywords in multi-token identifiers:
if account age < 13 then child account = true;
Here, if and then cannot be part of an identifier, so there is no ambiguity with account age and child account. Alternatively, you can require punctuation everywhere:
if (account age < 13) {
child account = true;
}
The last option is to make keywords pervasively context-sensitive, leading to such monstrosities as:
IF IF = THEN THEN ELSE = THEN ELSE THEN = ELSE
The biggest issue is that juxtaposition is an extremely powerful syntactic construct, and you don’t want to occupy it lightly. Allowing multi-token identifiers prevents using juxtaposition for another purpose, such as function application or composition. Far better, I think, just to allow most nonwhitespace characters and thereby permit such identifiers as canonical-venomous-frobnicator. Still plenty readable but with fewer opportunities for ambiguity.
I think it is bacause the designers of the language have followed this convention.
I have searched on Google and found that while naming a variable this is a rule which is followed while naming a variable.
Some links are given below:-
SPSS notes
The following rules apply to variable names:
Variable names cannot contain spaces.
C Programming/Variables
Variable names by IBM
Java Variable Naming convention
Variable names are case-sensitive. A variable's name can be any legal
identifier — an unlimited-length sequence of Unicode letters and
digits, beginning with a letter, the dollar sign "$", or the
underscore character "". The convention, however, is to always begin
your variable names with a letter, not "$" or "". Additionally, the
dollar sign character, by convention, is never used at all. You may
find some situations where auto-generated names will contain the
dollar sign, but your variable names should always avoid using it. A
similar convention exists for the underscore character; while it's
technically legal to begin your variable's name with "_", this
practice is discouraged. White space is not permitted.
Wiki for Naming Convention
In all of the above links you will find that the designers have followed this naming convention for naming the variable.
Also check Is there any language that allows spaces in its variable names
This is forced from language designing.
Compiler needs to find out the meaning of words.
Compiler works on a "State Machine" method, and it needs to distinguish key words.
Maybe placing variable names in "[" and "]" give us some solution(like SQL).
But it will be harder to use it in coding...
I recently read some of : https://www.rfc-editor.org/rfc/rfc6570#section-1
And I found the following URL template examples :
GIVEN :
var="value";
x=1024;
path=/foo/bar;
{/var,x}/here /value/1024/here
{#path,x}/here #/foo/bar,1024/here
These seem contradictory.
In the first one, it appears that the / replaces ,
In the 2nd one, it appears that the , is kept .
Thus, I'm wondering wether there are inconsistencies in this particular RFC. I'm new to these RFC's so maybe I don't fully understand the culture behind how these develop.
There's no contradiction in those two examples. They illustrate the point that the rules for expanding an expression whose first character is / are different from the rules for expanding an expression whose first character is #. These alternative expansion rules are pretty much the entire point of having a variety of different magic leading characters -- which are called operators in the RFC.
The expression with the leading / is expanded according to a rule that says "each variable in the expression is replaced by its value, preceded by a / character". (I'm paraphrasing the real rule, which is described in section 3.2.6 of that RFC.) The expression with the leading # is expanded according to a rule that says "each variable in the expression is replaced by its value, with the first variable preceded by a # and subsequent variables preceded by a ,. (Again paraphrased, see section 3.2.4 for the real rule.)