sparql-17-4-2-5 query parsed output malformed?

[yamalight]

Not sure here, but maybe there's an issue.

Query looks like this:

FILTER regex(str(?mbox), "@work\\.example$")

Output looks like this

{
  "type": "filter",
  "expression": {
    "type": "operation",
    "operator": "regex",
    "args": [
      {
        "type": "operation",
        "operator": "str",
        "args": [
          "?mbox"
        ]
      },
      "\"@work\\.example$\""
    ]
  }
}

Decoding "\"@work\\.example$\"" turns it into "@work\.example$" which is wrong.
Am I right here? That's a bug?

[RubenVerborgh]

In SPARQL literals, \\ is an escape sequence for a single backslash \. Therefore, the string "@work\\.example$" has contents @work\.example$, so the latter is the correct result.

It also makes sense: in example 17.4.2.5 of the SPARQL spec, the purpose of the regex is to match <mailto:alice@work.example>. In other words, the (single) backslash serves to escape the dot.

So the output is correct as far as I understand.

[yamalight]

@RubenVerborgh the problem here is that when you unescape "\"@work\\.example$\"" you'll get "@work\.example$" which differs from original SPARQL which looks like "@work\\.example$".
Which means that my generated queries will always be wrong here. So, that does looks like a bug to me. \\ should be escaped to \\\\ during parsing, then when unescaping back it will become \\ which is exactly what was there originally.

[RubenVerborgh]

I still think it's the same.

Language	Literal in language syntax	Interpretation (actual characters inside literal)
SPARQL	"@work\\.example$"	@work\.example$
JavaScript	'"@work\\.example$"'	"@work\.example$"

Note how the interpretation is the same in both languages (but the N3.js wraps all literals in double quotes).

In order to convert from the representation to SPARQL, you will need to escape the backslash.

Note that you generally never escape during parsing: parsing means unescaping, generating means escaping. (See for instance how we parse URLs.)

[yamalight]

Hmm.. Makes sense! Good, then I'll escape backslashes specifically during query generation.

[RubenVerborgh]

Yeah, that's probably something that needs to be done for all literal generation, because backslashes have special meaning.