<I-N-CA> XML Structure
Austin Tate, AIAI, University of Edinburgh
3-Oct-2001
---------------------------------------------------------------

domain.xml
      a description of a domain with global constraints, reusable
      refinements, grammars, lexicons, domain object type and
      attribute information, etc.

inca.xml
      a description of a synthesised artifact defined in terms
      of constraints on the set of all possible artifacts in a domain

inca-product.xml
      a description of the requirements or objective for an artifact and a
      specification of its realisation

subelements-inca.xml
      subelements used in inca.xml collected together for convenience

subelements-inova.xml
      subelements used for temporal activity and process extensions
      to inca.xml

subelements-config.xml
      sublements for a simple computer configuration example

example-plan.xml
      a simple example of a specialisation of inca-product.xml to
      describe a temporal activity plan.  The principle elements of
      this embeds 2 inca.xml models (for the objective and specification)
      In some planning systems, the objective is used as the initial
      specification prior to frther refinement.

inca.txt
      Notes and descriptions of the XML elements. Collected together
      rather than being embedded as comments in the XML files above.

Grammars and Lexicons

Any statement that appears within an I-N-CA model can be restricted in
the structure it can take.  This is done using a grammar and associated
lexicon for each statement.  An I-N-CA model may have a default grammar
and lexicon stated for each usage of statements in the model (via the
environment defaults element). If a default is not provided for the
uusage of a statament then there are no restrictions on the grammar and
lexicon which may be used (i.e. a copletely free grammar and lexicon
applies).  The default can be overridden for any individual statement
explicitly using grammar and lexicon attributes in the statement element.

I-N-CA Model Coverage

Note an I-N-CA model would usually be supplemented by additional models
describing the domain objects and their properties and possibly a
model of the relationmships between some domain objects in the domain
(such as agent relationships)

Common Elements

Any element can have the following additional sub-elements if not
already present:
          annotations
          constraints (on the specific structure or entity)
          views.

Refinement "Scope"

Each (sub-)node in a refinement is described by a pattern along with
the optional specification of a set of refinements (via their
refinement-ids) that may be used to refine that node.  If no
refinements are stated any available "unrestricted" refinement within
the domain model that matches the pattern and other constraints may be
used.

Refinement scope is either "unrestricted" or "restricted".

The following 2 items are optional, and only given in the case of a
restricted refinement
            outer-scope-id
            node-id - node within the outer scope which a restructed
                      refinement applies to

"self" is a reference to the current outer-scope node and may be used
in constraints and other elements.

node-id is unique within scope of the refinement it is within.

Constraints
         
Constraints have the general form:
         a) fixed constraint type keyword - e.g. resource, temporal, state
         b) any of a number of other items in the following preferred order
            statement (i.e. pattern [=value])
            to tp or to node-end (0..1 allowed)
            from tp or from node-end (0..N allowed)
         c) the following may appear where necessary
            symbols
            numbers 
            symbol=argument (e.g. object-1=<domain-object> or
                            mime-type="string")
            symbol="URL"

Timepoints

TP is an important type of domain-object specific to activity and
process domains.

Timestamps where used aaaaare in UTC format "yyyy-mm-dd hh:mm-ss.sss..."
(can add +hh.mm or -hh.mm for time zone)

A timestamp uses date (in UTC) or units on a given timeline - not both.

If timestamp is present it is interpreted as a relationship between a
time point and a timestamp which could have been stated separately.
It is allowed to be specified in the time point element for shorthand
and convenience.