Dynamically changing a skill without resubmission and recertification?
Background: =========== Where possible, I try to decouple mobile apps from configuration data to avoid another compilation, submission, review, certification, verion, review start-over, etc - no trivial feat. I accomplish this on iOS by using a JSON config file stored on my server and retrieved at app start up. Question: ======= I am wondering if it's possible to do a similar thing with a skill. While Amazon has said that any Schema or SampleUtterance changes will require recertification, why not just use a generic Schema interface that doesn't need to change (I think some forum threads have shown examples of this). The schema would accept all utterances and then let the dev's web-server process them as they wish. That way, in the future, the dev would be able to modify their code (or config file) on their server to process/say something different instead of resubmitting/recertifying with Amazon. Using the "Crystal Ball" skill as an example, this would work fine in the case where the dev wants to add a new response or remove an existing one. Same thing with the "Cat Facts" skill - if the dev needed to add, remove, or change a cat fact, this could all be done without Amazon's involvement. These would just be config items added and removed on the developer's server. As far as the need for Amazon to maintain "control," the analogy is a webview in a mobile app - the developer has complete control over it. It is just assumed that if it became profane, used inappropriately, violated standards, etc, the app (or skill in our case) would be pulled and the developer and their descendants would be banned for life... I.e. not worth it for the developer... I am asking whether this is possible both in order to learn if it can technically be done and to determine if this is a workable win/win strategy - it sure would save everyone a lot of effort, particularly as apps and voice recognition technology evolve. Thank you.
> The schema would accept all utterances and then let the > dev's web-server process them as they wish. Well, then you take on the job of having to do the natural language parsing. Also, you reduce Alexa into guessing what the best words are for a phrase. When you have an utterance file, you guide Alexa's recognition of what is spoken and significantly improve understanding. If you note, both the Crystal Ball and Cat Facts app don't really care about what the user says. If you have an app like that, then this approach is fine. Otherwise it is technically feasible, but is not what I would consider workable. Actually, I started to write a series of skills to help developers adjust their UI to the limitations of Alexa. The first one was a "record" app that just had a blank utterance, and printed on the companion app what it thought you said. I never pushed it to certification because it really didn't give a good idea of what Alexa's recognition would be like with an utterance file. But it did give an idea of what it would be like without one: bloody awful.