The .cphrase FormatFiles of the type .cphrase specify a model over the database that the administrator can update and extend. We give a complete description here.
To publish an NLI over a database, a special
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
PIM.cphrase that are delivered as working examples with C-Phrase.
We recommend that you peruse these files to get an idea of what typical
.cphrase files look like.
Conventions ThroughoutAll XML attributes named
idcannot start with a number or contain any special characters besides the underscore character '_'.
The Entire Configuration (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>
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
which would mean that both English and Swedish would be covered, but paraphrases and messages would be in
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 either
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.
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.