Validation breakdown

[jasonkuhrt]

We want to validate the user-specs. What different aspects of validation are there?

1. Is it a valid JavaScript Object?
2. Are all the used $operators actually defined? For each $operator that is being used but is not actually defined, is there a close match? Maybe the user just mistyped it.
3. Is each argument to each $operator satisfying the type constraints of that $operator?
4. Do the specified keys actually exist in the schema being matched against?
5. Do the types of $operators being used on keys match the types of those keys as defined in the schema?

I feel like there is more validation we could do in the actual structure of the spec too. Lets try and exhaust the possibilities.

[jasonkuhrt]

@sssyed Please let me know your thoughts. We should try to close this in order to confirm our first round of concrete issues.

[sssyed]

@jasonkuhrt absolutely. These validation tasks are the ones I'm focused on right now.

For additional validation I think we can find some inspiration from looking at error handling in compiler architecture. What i'm thinking is we can group validation under lexical, syntactical, or semantic analysis and check for errors on each respective phase. For example on the semantic level we could check for types but also lookout for expressions that would never be end up being true ( like we talked about before)

For example: { input : { $and: [ { $gt : 10 }, { $lt: 5}] } }

[jasonkuhrt]

Tell me if I am defining these correctly:

• syntactical: Are the syntax rules followed
• semantic: Does the filter make sense? (Really? Seems too vague. Isn't this really just a category of various checks that guarantee there are no logical impossibilities?)
• lexical: What is this?

[jasonkuhrt]

So in regards to the five initial points we have unearthed a sixth actually as @sssyed pointed out:

6 Guarantee there are no logical impossibilities e.g. this should be caught as an error:

{ input : { $gt : 10,  $lt: 5 } }

-- edit Aside: Also @sssyed See how I expressed the same thing in simpler terms; It leverages the fact that the default semantic of keys is $and.

[sssyed]

@jasonkuhrt Yup! I used this as a rough reference: http://en.wikibooks.org/wiki/Compiler_Construction/Dealing_with_errors#Compile-time_Errors

One possible validation at the lexical phase would be checking for invalid numbers: +/- 9007199254740992 or whatever the largest int +1 and smallest int -1 might be in javascript.

[jasonkuhrt]

@sssyed when I wrote "What is this" I literally was asking the question to you : ) Sorry not clear haha.

[sssyed]

@jasonkuhrt oh! haha : )

[jasonkuhrt]

Ok I think this is good enough.

To recap here are the kinds of validation we are currently conscious of. I've written a brief example for each kind.

1. In the spec, each function used, must be defined in the standard library:

{ input: { $whoops: 5 } }

Errors:

(1) Function "$whoops" is not defined.

{
  input: {            
    $whoops: 5
     ^^^^^^ (1)
  }
}

Solutions:

(1) <docs about the standard library>

2. In the spec, each function argument, must type-match and be within constraints of its respective parameter.

{ input: { $gte: ["nonsense"] } }

Errors:

(1) Type Error: Argument '["nonsense"]' to function "$gte" does not match its parameter's type.: String, Number

{
  input: {            
    $gte: ["nonsense"]
          ^^^^^^^^^^^^ (1)
  }
}

Solutions:

(1) <$gte docs>

3. In the spec, each key accessed, must be defined in the schema.

{ whoops: { $gte: 5 } }

Errors:

(1) Schema Error: The specified key "whoops" does not exist in the BlahBlah schema.

{
  whoops: {            
  ^^^^^^ (1)
    $gte: 5
  }
}

Solutions:

(1) <BlahBlah schema info>

4. In the spec, each used function must have its parameter that accepts the key's value, type-match and be within constraints of that key's value.

{ from: { $gte: 5 } }

Errors:

(1) Schema Error: The function "$gte" only works on keys with values of type "String" or "Number" but was used on key "from" which has incompatible type of value of "Map".

{
  from: {            
    $gte: 5
     ^^^ (1)
  }
}

Solutions:

(1) <BlahBlah schema info and $gte docs>

5. The overall spec must be possible to satisfy.

{ input: { $gte: 5, $lte: 3 } }

Errors:

(1) Impossible Spec: The given spec is impossible to satisfy. Key "input" can never be "gte" to "5" AND "lte" to "3".

{
  input: {
    $gte: 5,
     ^^^ (1)
    $lte: 3
     ^^^ (1)
  }
}

Solutions:

(1) <Suggestion about how to fix the impossibility>

[jasonkuhrt]

@stresslimit @sssyed See above comment for final recap. I've written example errors too. The actual design of those errors will be a formal issue/discussion so don't take what I've done too literally, just quick wishful thinking.