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

$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.

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:

...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:

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:

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.

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.

Example

In the above example, the Expansion used to make “please” optional can be rewritten as in the third line. When the grammar is parsed, the Engine 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:

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.

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.

$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.