The .cphrase Format
Files 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 .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 C-Phrase.
We recommend that you peruse these files to get an idea of what typical .cphrase
files look like.
Conventions Throughout
All XML attributes namedid
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.