Add known spec deviations (regex) to EE docs (#55)

* add known spec deviations (regex) to EE docs

* uri fix

* Apply suggestions from code review

---------

Co-authored-by: Ruben Taelman <[email protected]>

pages/docs/2_modify/advanced/expression-evaluator.md

@@ -6,7 +6,7 @@ description: 'The expression evaluation engine of Comunica.'
 To evaluate expressions, Comunica uses a collection of packages that are part of the Comunica monorepo.
 Two buses specifically are of importance:
 * [`@comunica/bus-expression-evaluator-factory`](https://github.com/comunica/comunica/tree/master/packages/bus-expression-evaluator-factory): Creates an expression evaluator, more info listed bellow.
-* [`@comunica/bus-function factory`](https://github.com/comunica/comunica/tree/master/packages/bus-function factory): creates function, more specifically it creates objects that are able to evaluate the desired function given the arguments.
+* [`@comunica/bus-function factory`](https://github.com/comunica/comunica/tree/master/packages/bus-function-factory): creates function, more specifically it creates objects that are able to evaluate the desired function given the arguments.
 
 Two different kind of functions are used `TermFunctions` and `ExpressionFunctions`, and TermFunction extends ExpressionFunction.
 An `ExpressionFunction` is a function that takes control over the evaluation of its arguments, meaning that the argument of an ExpressionFunction are Expressions and not Terms.
@@ -190,3 +190,23 @@ The expression evaluator also handles **[type promotion](https://www.w3.org/TR/x
 Type promotion defines some rules where a types can be promoted to another, even if there is no super-type relation.
 Examples include `xsd:float` and `xsd:decimal` to `xsd:double`and `xsd:anyURI` to `xsd:string`.
 In this case, the datatype of the term will change to the type it is promoted to.
+
+
+## Deviations from the SPARQL specification
+
+Two functions have known deviations from the SPARQL specification in a few minor edge-cases.
+These are the
+[regex](https://github.com/comunica/comunica/tree/master/packages/actor-function-factory-term-regex)
+and
+[replace](https://github.com/comunica/comunica/tree/master/packages/actor-function-factory-term-replace)
+functions.
+These two functions require the implementation of a Regular Expression Engine.
+Instead of implementing and bundling our own implementation of such an engine,
+we use the implementation provided by the JavaScript language (in unicode-mode, without [Annex B](https://262.ecma-international.org/6.0/#sec-regular-expressions-patterns)).
+This choice saves bundle size and probably execution time in comparison to implementing our own engine.
+Furthermore, it reduces implementation and maintenance cost on our side.
+As a result of using the JS Regex Engine, our implementation of those functions has some known non-spec compliant edge cases,
+examples of which can be found in the skipped test blocks in
+[op.regex-test.ts](https://github.com/comunica/comunica/blob/master/packages/actor-function-factory-term-regex/test/op.regex-test.ts)
+and
+[op.replace-test.ts](https://github.com/comunica/comunica/blob/master/packages/actor-function-factory-term-replace/test/op.replace-test.ts).