Expression Pattern Language (eXPL)

Resources

Resources are external systems used to input and output data. A simple Java interface (ResourceProvider) is provided so developers can connect to resources. Examples of coding to this interface can be found in the following tutorial applications:

  1. Tutorial 4 InWords for input connects to a file containing dictionalry definitions and for output, to the console
  2. Tutorial 13 ForeignColors executes one query to write axiom collections to the file system and another query to read the axiom collections back. Each collection belongs to a separate scope.

Further examples using relational databases as resources can be found in a separate project - see eXPL Extensions. Instructions on how to develop a resource provider in Java are yet to be written but the tutorial examples provide models to work from and code that can be adapted to suit particular requirements.

Resource Management

Resource declarations are allowed only at the beginning of a program and must precede any other statements. When a resource statement is encountered, a resource provider method is called to open the resource. A call to close the resource is subsequently made after the query is completed and this happens even when the query fails with an error. There is no compulsion for a resource provider implementation to do anything in particular for open and close and it is up the the overall application architecture what operations, if any, these functions should do. However on close, it is expected for data integrity that any cached data will be stored permanently and any pending synchronization operations will be completed.

Resource Format

A resource declaration can potentially contain many parts depending on the complexity of the external system. All resources are marshalled and unmarshalled as axiom collections and the resource format is consistent with the formats for other types of axiom collections. Each collection has a name. A collection being imported has a header containing a list of term names while one being exported has the keyword export. A resource declaration can be bi-directional and include an external system name in quotes plus optional properties:

Import-only
resource name axiom ( term-names )
[ = "system-name"] [ ( properties ) ];

The name can be 2-part, the first part specifying a scope. Application ForeignColors is an example. The term names are applicable to the entire collection, both in case and sequence order. When the resource name is sufficient to identify the underlying resource, the system name is optional . However, if more than one resource is managed by a provider, then the system name is required to identify the provider. The system name may also be required if the external system requires a name with a format not supported by eXPL eg. a name starting with a dollar symbol.

The optional properties are a list of name-value pairs. The name is a 1, 2 or 3-part name. The value must be a literal. If a system property requires a name that does not comply ith eXPL format, then the provider will need to map an eXPL name to an external name.

Export-only
resource name export [ = "system-name"] [ ( properties ) ];

The axiom header is replace by the "export" keyword. The resource name in this case identifies the name of a template which produces solution axioms to be exported. This template will be automatically created if not included in the program. The other parts of the declaration are the same as for the Import-only case.

Import+Export
resource name axiom ( term-names ), export name
[ = "system-name"] [ ( properties ) ];

The export part follows the import axiom header, separated by a comma. Note the export resource name is independent of the import one. The InWords application has an example of a bi-directional declaration and also uses a resource name to match that of program's only template. Here is the resource declaration and template:

resource lexicon
axiom(word, definition),
export in_words;

template in_words (regex word ? "^in[^ ]+", definition);