The .cphrase Format

Files of the type .cphrase specify a model over the database that the administrator can update and extend. An administrator seeking mastery must fully understand the XML-based .cphrase Format. We give a complete description here.

To publish a C-Phrase NLI over a database, a special .cphrase configuration file must be maintained. This file defines what tables (and views) can be accessed and with what phrases. The examples discussed here are drawn from the .cphrase files: geo.cphrase, northwind.cphrase and PIM.cphrase that are delivered as working examples with the C-Phrase. We recommend that you peruse these now to get an idea of what typical .cphrase files look like.

Conventions Throughout

All XML attributes named id cannot start with a number or contain any special characters besides the underscore character '_'.

The Entire Configuration (the config element)

The config element is always root element in a .cphrase file. Its DTD-based definition is: 

<!ELEMENT config (table|view|command|report|empty|cascade|db_state|execute)*>
<!ATTLIST config
          id CDATA #REQUIRED
          db CDATA #REQUIRED
          language CDATA #IMPLIED>

Tag Attributes

The tag attribute id is the name of the configuration.

The tag attribute language is an optional comma separated list of languages with the first language being the dominant one. Its default value is language="english". Since C-Phrase currently only supports Swedish and English, this could in its most complex form be language="swedish,english" which would mean that both English and Swedish would be covered, but paraphrases and messages would be in Swedish.

The tag attribute db specifies how to connect to the underlying database. In stand-alone mode the actual database may not be built yet. If so, then launching NLIs will result in an error message reminding the administrator to build an SQLite database. The specific format of the db attribute is a text string that always starts with eitherpostgresql:,mysql: or sqlite: followed by a connection string. In the case of SQLite, the connection string is simply the name of the database file. For example,db="sqlite:personal.db" specifies the local SQLite database. See the database connection string documentation for remote databases.

Sub-elements

Within the config element, sub-elements represent tables, views, commands, reports and then string processing directives in cascade. It might also contain a list of tuples within a db_state element that represent a database state. Finally there is an optional execute element which defines an SQL script that is executed over the underlying database immediately before an NLI is launched.