I've been messing with the OData and realized that URIs are case sensitive. .../Northwind.svc/Products != .../Northwind.svc/products
Is this done on purpose? is there a way to make it case insensitive?
The recommended solution is to either use the supported OData functions toupper or tolower to work out the case sensitivity issues (when using a filter$ command) and get the full result set.
I wrote a brief post explaining this a bit further in detail:
Dealing With Case Sensitivity in OData
Here's an example:
/people?$filter=tolower(Name) eq tolower('jAmes') -
This would return you all people with name is 'James' (case insensitive, could be 'JAMES', 'james', 'JamES', etc.
Hope this will help
Related
My question is simple but maybe non-sense. (in that case , sorry to people who gonna spend time to explain me why )
I'd like to create a resource like (i dont show all the resource declaration here ) :
<owl:DatatypeProperty rdf:about="relation:isPartOf">
<rdfs:domain rdf:resource="http://www.w3.org/2004/02/skos/core#note"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI"/>
</owl:DatatypeProperty>
<rdf:Description rdf:about="resource:context:sc#c1">
<skos:note rdf:datatype="relation:isPartOf" rdf:resource="resource:context:sc#c2">
</skos:note>
</rdf:Description>
Important to see is the triple about a skos:note relation
Subject : c1 a uri. Predicate : a skos:note , Object : a typed URI
My URI is not a direct URI but a "relation;isPartOf" uri.
I create a custom typedUri class to do that / i used a home made triple store so i can use my own class.
I change a little bit the RDFXMWritter to output these example. so "it works".
My question is more : Can a URI be typed like this ? why sesame openrdf do not provide a TypedURI class ? I'm sure there is a good reason ? any help, ideas or answers would be nice.
i'm quite sure , my idea to create a TypedURi class is wrong somewhere . but where ? :-)
thank you
EDIT : the TypedURI is not really a new kind of resource. The URI in my context is still a URI. i just declare that inside my skos:note statement , that for c1 , the object of the statement is a data of type "relation:isPartOf" and the range of the data is a anyURI.
... The typedURI helps to implements the datatype with such a range.
First of all: no, a URI can not be typed like this in RDF. Which also answers your second question: OpenRDF Sesame does not provide this functionality because it is not part of the RDF model.
Typing of URIs (or more accurately, resources, which are identified using URIs) is done by using an rdf:type relation, linking the resource URI to a class URI. For example, to make the resource ex:p1 of type foaf:Person, we would say (using Turtle syntax for RDF):
ex:p1 rdf:type foaf:Person .
There's another kind of typing in RDF, namely datatyping. This only applies to literal values so it can not be used on a URI. It is used to make a literal value a string, an integer number, a date, etc.
Update a confusion may arise because xsd:anyURI is a valid datatype in RDF, and it is (in XML Schema) defined to be a type for URIs. However, when using a datatype in RDF, its lexical space is always a literal (simply because the spec only allows for literals to actually have a datatype). So you could indeed do something like this (using Turtle syntax for literal notation):
"http://www.example.org/some/uri"^^xsd:anyURI
But from the point of view of the RDF model, this is not a URI, but a literal string (with datatype xsd:anyURI). So in a sense, yes, you can add types to URIs in RDF, but you can only do this by "converting" them to literals first.
we have a web service that is supposed to be case insenisitive. So, we want the same result on a search for 'foo' and 'FOO'. What is the best way to create an assertion that compares the response for the two different string parameters?
Thank you!
I would not compare the two results at all. Your tests could just test the response you receive. So if you are testing each response the same you would be verifying the responses match.
If using soapUI open source, I would create two tests that are exactly the same except for the data, probably use a test case property. My requests and response assertions would be the same, but the data is extracted.
If I'm using soapUI Pro, I could have one test case that uses a data sheet, which is alot easier to maintain going forward, but that costs money.
If you want to know what exactly to assert in your test, you will need to look at your requirements and decide which pieces are important to assert. If the answer is the whole request a simple xpath match against the entire soap envelope would work.
If you must, groovy is the answer, I think something like this should work:
def rawRequest = context.expand( '${Teststepname#RawRequest#declare namespace soapenv=\'http://schemas.xmlsoap.org/soap/envelope/\'; //soapenv:Body[1]}' )
def rawRequest2 = context.expand( '${Teststepname2#RawRequest#declare namespace soapenv=\'http://schemas.xmlsoap.org/soap/envelope/\'; //soapenv:Body[1]}' )
if (rawRequest == rawRequest2) {
assert true
}
else {
assert false
}
Should the following URLs be considered functionally equivalent?
http://example.com/foo?a=&b=
http://example.com/foo?a&b
This came about when a user of a Drupal module I wrote which parses apart and then rewrites URIs noticed that the code sometimes causes the query string parts to change in unexpected ways due to how some of the underlying PHP functions behave. For example:
parse_str("a&b", $values); print http_build_query($values);
a=&b=
Is this something I should bother worrying about?
Edit so SO stops complaining that this question is similar to another one: The question is whether it's safe to assume that "no value for X" and "empty value for X" are equivalent, not whether the "no value" style is syntactically correct (which it is).
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax doesn't have anything to say about the structure of the query string aside from how characters like ? should be dealt with. So strictly speaking, your two example URLs are different. Of course, the application which receives those query strings may treat them as functionally equivalent, but this isn't something you can determine from the URL alone.
As per RFC6570 empty query parameters are allowed. Please refer to section 3.2.9
Example Template Expansion
{&x,y,empty} &x=1024&y=768&empty=
I'm doing some client-side stuff with Javascript/JQuery with .Net controls which expose their GUID/UniqueIdentifier IDs on the front end to allow them to be manipulated. During debugging something is driving me crazy: The GUIDs in the db are stored in uppercase, however by the time they make it to the front end they're in lowercase.
This means I can't quickly copy and paste IDs into the browser's console to execute JS on the fly when devving/debugging. I have found a just-about-workable way of doing this but I was wondering if anyone knew why this behaviour is the case and whether there is any way of forcing GUIDs to stay uppercase.
According to MSDN docs the Guid.ToString() method will produce lowercase string.
As to why it does that - apparently RFC 4122 states it should be this way.
The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.
Also check this question on SO - net-guid-uppercase-string-format.
So the best thing you can do is to call ToUpper() on your GUID strings, and add extension method as showed in the other answer.
If you're using an Eval template, then I'd see if you can do this via an Extension method.
something like
public static string ToUpperString(this Guid guid, string format = "")
{
string output = guid.ToString(format);
return output.ToUpper();
}
And then in your Eval block,
myGuid.ToUpperString("B")
Or however you need it to look.
I'm on my Mac at the moment so I can't test that, but it should work if you've got the right .Net version.
Is this a valid http url
http://www.example.com?x&y
or
we must always have = sign for parameters.
http://www.example.com?x1=x&x2=y
Well, it works, and the W3C recommendations are extremely general -- only the use of ? and + are defined. So I think from the perspective of HTTP/HTML the = is optional. It's use is obviously a common convention and many client & server libraries use it, but there doesn't seem to be any reason you couldn't define a service to work on some other scheme.
Anecdotally, I like to leave out the =blah part when I'm using the query string as a flag as in http://www.example.com?logout
Reference: http://www.w3.org/Addressing/URL/4_URI_Recommentations.html
According to the ABNF in Appendix A of RFC 3986, both examples above are valid URL.
Note that if you read only the Wikipedia article on Query string, you might get the false impression that the second ne is the only valid one.