AMAZON.LITERAL utterances parsing

[cnadeau]

Hi, I'm trying to use the lib, but I have a literal which doesn't seem to be properly parsed by the bespoken/virtual-core lib. Any idea how to get that processed correctly?

PS: I love this lib and I really want to use it. I'm pretty sure the problem is the format of the LITERAL slot with the pipe, but I'd rather ask you guys first.

If you have an idea and not time, just throw it in I'll do my best to get a PR up for that.

Intent:

{
          "name": "LiteralInput",
          "slots": [
            {
              "name": "literal",
              "type": "AMAZON.LITERAL"
            }
          ],
          "samples": [
            "{test | literal}",
            "{test2 | literal}",
          ]
}

Error:

Error: Invalid schema - not slot: test | literal for intent: LiteralInput
      at SamplePhraseTest.checkSlots (node_modules/virtual-core/lib/src/SampleUtterances.js:128:23)
      at new SamplePhraseTest (node_modules/virtual-core/lib/src/SampleUtterances.js:78:36)
      at SamplePhrase.matchesUtterance (node_modules/virtual-core/lib/src/SampleUtterances.js:54:16)
      at Utterance.matchIntent (node_modules/virtual-core/lib/src/Utterance.js:49:41)
      at new Utterance (node_modules/virtual-core/lib/src/Utterance.js:7:14)
      at LocalSkillInteractor.SkillInteractor.spoken (node_modules/virtual-alexa/lib/src/impl/SkillInteractor.js:64:25)
      at VirtualAlexa.utter (node_modules/virtual-alexa/lib/src/core/VirtualAlexa.js:53:33)

[jkelvie]

Hi @cnadeau - I'm not familiar with the syntax that uses the pipe - that is the problem. Is this a supported notation? I can't find any docs on it.

Additionally, keep in mind that you can also just call intend - described here and pass in the explicit intent and slot that you want.

[cnadeau]

Hi @jkelvie , thanks for the ultra fast answer!

Here is the documentation of AMAZON.LITERAL

You're absolutely right, I was trying to to force an intent, but that's a good workaround for now.

Thanks!

[jkelvie]

Hi @cnadeau - I missed this PR - apologies. What problem does adding these builtin slot types solve? I am asking because we generally just treat the builtins as literals (passing through whatever value is provided by the user), with the exception of the Number type.

We plan to add other types over time where the default behavior does not work or would benefit from some transformation - for example, a DATE slot type to automatically convert date values into the correct format. But in the case of Search and Literal, I believe the default behavior is fine. Am I wrong?

[cnadeau]

Hi @jkelvie , as mentioned above, the schema could not be parsed and prevents any tests from being executed.

Adding at least there definition and treating them as literals for Literal and SearchQuery actually solves that problem

[jkelvie]

Sorry, my comment was with regard to this PR:
#67

I should have added it there. Given that context, does it make sense what I'm saying?