It's all about the answers!

Ask a question

OSLC Query with double quote


Steven Wallace (333) | asked Jan 18, 12:58 p.m.
retagged Jan 19, 8:11 a.m. by Ian Barnard (1.2k613)
While using DoorsNG, I'm having an issue querying for a title that includes multiple double quotes. I've attempted to escape the quote and still haven't had luck in getting it to work. Any ideas?

Example query:

https://<server>:<port>/rm/views?oslc.query=true&projectURL=https://<server>:<port>/rm/process/project-areas/<project area>&oslc.prefix=dcterms=%3Chttp://purl.org/dc/terms/%3E&oslc.select=dcterms:title&oslc.where=dcterms%3Atitle%3D%22This%20value%20%5C%2211%5C%22%22

Comments
Ian Barnard commented Jan 19, 7:47 a.m. | edited Jan 19, 7:50 a.m.
JAZZ DEVELOPER
Converted to answer

2 answers



permanent link
David Honey (7756) | answered Jan 19, 5:53 a.m.
JAZZ DEVELOPER

Unfortunately the OSLC Query specification (https://docs.oasis-open-projects.org/oslc-op/query/v3.0/os/oslc-query.html) does not define any mechanisms for quoting characters in string values. The specification does permit implementations to support wildcards, but implementations may choose not to do so - see Section7.2.3 oslc.where Semantics. For example, a query expresssion dcterms:title="This value%11%" might be supported and might match a value such as This value "11" . Currently there is no way to discover at run time whether a server supports this capability. A client can try a particular server to see if the request succeeds and produces what it is wanted. Some implementations might have supported "*" as a wildcard, but such usage was never part of any OSLC specification.


Comments
David Honey commented Jan 19, 9:54 a.m.
JAZZ DEVELOPER

I was mistaken about quoting. The spec says this:

The string_esc term represents an arbitrary sequence of characters. The sequence of characters is enclosed in double quote (") characters. Therefore, the double quote character itself MUST be escaped. More generally, all occurrences of the double quote character in the string MUST be replaced by the sequence \" and all occurrences of the backslash character \ in the actual value MUST be replaced by the sequence \ in the escaped value. This escaping process MUST be reversed to give the actual value of the string. [QUERY-22]


Steven Wallace commented Jan 19, 10:02 a.m.
Per the spec:
The string_esc term represents an arbitrary sequence of characters. The sequence of characters is enclosed in double quote (") characters. Therefore, the double quote character itself MUST be escaped. More generally, all occurrences of the double quote character in the string MUST be replaced by the sequence \" and all occurrences of the backslash character \ in the actual value MUST be replaced by the sequence \\ in the escaped value. This escaping process MUST be reversed to give the actual value of the string. [QUERY-22]

Is this limited to only some types of elements?

David Honey commented Jan 19, 10:09 a.m.
JAZZ DEVELOPER

It only applies to string literal values in oslc.where query expressions. The spec shows the syntax (excerpted):

    value         ::= uri_ref_esc | PrefixedName | literal_value
    uri_ref_esc   ::= / an angle bracket-delimited URI reference in which > and \ are -escaped. /
    literal_value ::= boolean | decimal | string_esc (LANGTAG | ("^^" PrefixedName))?
    boolean       ::= "true" | "false"
    decimal       ::= / see "XML Schema Part 2: Datatypes Second Edition", http://www.w3.org/TR/xmlschema-2/ /
    string_esc    ::= / a string enclosed in double quotes, with certain characters escaped. See below. /
    LANGTAG       ::= / see "SPARQL Query Language for RDF", http://www.w3.org/TR/rdf-sparql-query/#rLANGTAG /


permanent link
Ian Barnard (1.2k613) | answered Jan 19, 7:50 a.m.
JAZZ DEVELOPER
edited Jan 19, 8:01 a.m.

This type of query where embedded " is escaped as \" certainly works with DOORS Next 7.0.2 iFix009. Note the comparison is case-sensitive and so must precisely match the title you're searching for.


FYI I don't see any difference between escaping one " or multiple " - the escaping works as expected whatever the number of " embedded in the title.

What version+ifix are you using? If not the latest you should update to the latest iFix and test again.



Comments
Steven Wallace commented Jan 19, 9:49 a.m.

Yeah, thought it might be a bug. We're currently using 6.0.6 iFix012.

Your answer


Register or to post your answer.