SISR Basics

This article covers the building blocks of SISR — tags, rule variables, and tag formats. If semantic interpretation is new to you, start with Intro to Semantic Interpretation for the background; here we get concrete about how SISR is written.

Tags

Tags are how SISR is embedded in a grammar, and a tag almost always contains ECMAScript. The recognizer executes the script in a tag as soon as the portion of the rule to its left is matched.

In ABNF, a tag is delimited by curly brackets, { and }. Because ECMAScript also reserves the brace — for conditionals and the like — a tag whose code contains its own braces must be delimited differently: open it with {!{ and close it with }!}.

In GrXML, a tag is the <tag> element.

The two grammars below are equivalent: both listen for "hello" and return "Hello, world." when matched.

ABNF:

Or, using the three-character delimiters:

GrXML:

If a matched rule contains several tags, they execute left to right. When a rule has alternatives, a tag inside an alternative runs only if that alternative matched. For example:

If the caller says "yes," only the first tag runs — the second alternative never matched. Now contrast:

Here, saying "yes" executes both the first and second tags, because the {out = "Definitely"} tag sits outside the alternatives and so is not gated by either; saying "no" executes the first and third. Within any single tag, ECMAScript statements likewise run left to right.

Rule Variables

Every rule has an associated value, its rule variable. A rule’s SISR tags modify that variable, and the rule variable of the grammar’s root rule is what the grammar returns as its interpretation.

If a rule has no SISR, its variable defaults to the raw text that matched — whatever the speaker said. Consider:

This matches "Robert," "Robert Smith," "Bob," or "Bob Smith." With no SISR attached, the rule’s out variable is simply the matched text: say "Robert Smith" and out is "Robert Smith"; say "Bob" and it is "Bob."

Because the recognizer ultimately returns the root rule’s variable, writing SISR comes down to writing tags that shape what that root variable ends up holding.

Tag Formats

SISR comes in two flavors.

The first, String Literals, uses no ECMAScript: whatever sits inside a tag is placed directly into the rule’s variable as a string. Applied to the same rule:

Now, whether the speaker says "Robert," "Robert Smith," "Bob," or "Bob Smith," the grammar returns the string "Robert Smith."

String Literals is a good fit for simple applications that need no logic on the interpretation. Its limitation is exactly that: you cannot perform operations on rule variables — you cannot combine them, so when two rules match there is no way to preserve both pieces of SISR information.

SI Script, the second flavor, removes that ceiling. Each tag holds ECMAScript that runs when its rule is matched. It is more cumbersome to write, but it gives you full control over rule variables. You cannot mix the two formats within a single grammar.

Every SISR grammar declares its tag format in the header — in ABNF with a tag-format line, in GrXML with the tag-format attribute on the <grammar> element.

Capacity Private Cloud supports both the final SISR 1.0 Recommendation and older drafts. As a result, when STRICT_SISR_COMPLIANCE is disabled it deviates from the official SISR 1.0 recommendation in the tag-format strings it expects. The W3C specifies semantics/1.0 for SI Script and semantics/1.0-literals for string literals; but in backward-compatibility mode (STRICT_SISR_COMPLIANCE disabled), Capacity Private Cloud requires semantics/1.0.2006 and semantics/1.0.2006-literals instead — plain semantics/1.0 reverts to an older draft. See Tag Format for the full list of accepted formats.

ABNF header example:

GrXML header example:

To start adding SISR tags, see Rule Variables.

Related Articles

• Intro to Semantic Interpretation
• Rule Variables
• SI Script by Example
• Getting the Return Value
• Advanced SISR Results
• Converting from Older SISR