The .cphrase FormatAny database administrator (DBA) who wants mastery over C-Phrase must fully understand the
.cphraseFormat. We give a complete description here. For even more insight read this paper.
To publish a C-Phrase NLI over a database, a special
file must be maintained. This file defines what tables
(and views) can be accessed and with what phrases. In remote mode, where the interface is to a remote, already existing database,
the first step is to import the remote database's schema into an initial .cphrase file which is then edited.
In stand-alone mode, where an SQLite database is built on the C-Phrase server, an initially empty
file is built up from which later an SQLite database is built. Either way, the authoring of the NLI will be
The examples discussed here
are drawn from the
.cphrase files: geo.cphrase, northwind.cphrase
and personal.cphrase. We recommend that you peruse these now to get an idea of what typical
.cphrase files look like.
The Entire Configuration (the
config element is always root element in a .cphrase file. Its DTD-based definition is:
<!ELEMENT config (table|view|report|pre|post|response|state|execute)*> <!ATTLIST config id CDATA #REQUIRED db CDATA #REQUIRED language CDATA #IMPLIED>
The tag attribute id is the name of the configuration. It is required.
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. It is always present although 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
sqlite: followed by a connection string. In the case of SQLite,
the connection string is simply the name of the database file. For example,
specifies the local SQLite database. See the database connection string documentation for remote databases.
c-phrase element, sub-elements represent tables, views, reports and then
string processing directives pre, post
and response. It might also
contain a list of tuples within a 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 every time an NLI is launched.