Special rules

In addition to the rules you create, there are several reserved rules outlined in section 2.2.3 of the SRGS Specification. These rules dictate special behavior for the Speech Engine.

While helpful and functional, these rules should be considered best used either temporarily or as a last resort because they can negatively affect the processing during decodes. In almost every case, the same result that can be obtained through these special rules can also be achieved through programming.

These rules are:

• GARBAGE
• VOID
• NULL

In ABNF, the way to reference a special rule is to use $NAME where NAME is the name of the special rule, in all caps (e.g. $GARBAGE). In GrXML, special rules are referenced by <ruleref special="NAME" /> where NAME is the name of rule in all caps (e.g. <ruleref special="GARBAGE" />). Note that the attribute special is used with <ruleref> here instead of the normal uri attribute.

GARBAGE

The GARBAGE rule functions like a wild card. It filters out any words that are not matched by the other words within its rule and discards them.

You would only want to use it temporarily at best, as it can greatly increase the decode time. It should not be used to create a hot word or keyword spotting grammar - this will not work.

ABNF Example

GrXML Example

The above grammar would allow the user to say "no", "no, thank you", or "no, you stupid machine." All that would be returned would be the matched "no" rule. "Thank you", "you stupid machine" or anything else spoken after “no” would not be returned as part of the answer.

Note that engaging the out-of-vocabulary filter can slow down recognition times, and even cause additional misrecognitions if used too aggressively.

If possible, we recommend creating specific "filler entries” using grammar rules. These would match frequently occurring out-of-vocabulary words instead of using the GARBAGE rule. For example, it is often better to use a rule like:

ABNF Example

GrXML Example

...instead of the GARBAGE rule, assuming your users are frequently giving responses like the ones mentioned above.

This is because while you don’t need the filler words for your interpretation, they do actually add to the confidence of the match. “No” has the same interpretation as “no, thank you.” But when those filler words are matched, it increases the likelihood that the Engine has decoded the entire utterance correctly.

The GARBAGE rule is tempting because it would seem to alleviate the need to account for any number of possible words around those in your grammar. However, it also presents the possibility of getting false positive matches. This would be where a match is made incorrectly.

The reason for this is that if the GARBAGE rule matches anything around its grammar entry, it’s also possible that you’ll be matching entries in the GARBAGE rule when you don’t want to. See the example below:

ABNF Example - How NOT to Use the GARBAGE Rule!

GrXML Example - How NOT to Use the GARBAGE Rule!

In this example, the parse “no idea” is intended to match the dontknow rule, and it would. But in this case, it will also match the no rule, and probably return it as the first interpretation.

VOID

The VOID rule invalidates any matched rule that contains it, and hence any answer that contains it. In other words, it throws away any input that matches the rule.

The VOID rule is most effectively used as a preventative against giving nonsensical input. Suppose that you have a flight booking application that sometimes misrecognizes "San Diego" and "San Francisco." This could result in a nonsensical flight request, e.g. San Diego to San Diego. To counter this, you could use the VOID rule to prevent the destination from matching the departure:

ABNF Example

GrXML Example

Ideally, you would want to write a grammar that only contains valid destination/departure combinations in the first place. But, explicitly enumerating all of these combinations would be much more tedious than simply disallowing the specific unwanted destination/departure combinations. In this case, the VOID rule is a simple and effective way of eliminating possible misrecognitions without a huge undertaking.

The VOID rule is one of the most difficult rules to use correctly, and is misused more often than not. It’s sometimes most easily understood by explaining how NOT to use it, as with the example below.

Ultimately, it discards the match. At a glance, it’d seem perfect to use to deter people from providing an unwanted response. Users often try to use the $VOID rule to throw out values they don’t want like “operator” in a yes/no grammar.

ABNF Example - How NOT to Use the $VOID Rule!

GrXML Example - How NOT to Use the $VOID Rule!

In this example if the caller says “operator”, the VOID rule will force the recognition to be either “yes” or “no”, and will end up getting a low confidence. The result will basically be the same as not having the operator word in the grammar at all – the application will either misrecognize or reprompt due to a low confidence score.

NULL

The NULL rule is automatically matched as soon as it is processed by the Engine, without the user having spoken anything. It is a programming tool, and is matched as the text of the grammar is parsed.

The NULL rule is illustrated below with standard grammar operations rewritten to use the NULL rule.

ABNF Example

GrXML Example

In the above examples, the expansion used to make “please” optional can be rewritten as in the second rule. When the grammar is parsed, the ASR automatically knows that it can choose to match either “please” or NULL. Since it has to match NULL automatically, it can return with a valid parse without matching the word “please.”

Since the above example simply takes more keystrokes to accomplish the same feature when using the $NULL rule, let’s look at a more practical application.

In the example below, you’re building a numbers grammar, which you want evenly weighted:

ABNF Example

When the speaker says any number in the twenties, they have an option to state a number between twenty and twenty-nine. This grammar will let them say the word “twenty” and then they can optionally use the $OneToNine rule to specify additional values.

The $twenties rule specifies that the caller can either say something from within the $OneToNine rule, or not.

However, if this rule implies that there is just as likely a chance of the speaker saying “twenty” as there is of them saying any other number within the twenties. Statistically, this may not be accurate. Each number within the twenties should have a one-tenth chance of being said.

To counter this, you would add weights to the $twenties rule to bring the NULL option’s weight down to 10%, and increase the $OneToNine rule’s weight up to 90%:

Now the NULL rule is automatically matched, which only serves the purpose of taking up one-tenth of the weight of the $twenties rule. However, this is an important component of this rule, since you want all possible numbers in the twenties to have an equal likelihood of being matched.

In GrXML, this same grammar takes the form:

GrXML Example

As is the case with the VOID rule, there are cases where you would not want to use the NULL rule.

In the example below, the $word rule can be repeated an infinite number of times, as defined by the <0-> operator.

ABNF $NULL rule Example - How NOT to Use!

GrXML $NULL rule Example - How NOT to Use!

Other cases where the NULL rule are used are simply unnecessary and may slow down compilation or the parsing of the grammar.