Part 1. The Validator Algorithms
Here is the basic Validator algorithm for doing this, defined in pseudo-code:
validator(TopicMap map, String logFile} throws Exception
for each topic, T, in map, use these methods to dump to logFile:
{
for each propType, P, call checkProp(T, P, {P's string value})
for each nameType, P, call checkProp(T, P, {P's string value})
for each roleType, R, call checkRole(T, R, {R's association))
}
exit
This trivial algorithm uses only two methods, which in Java have these signatures:
checkProp(Topic subject, Topic propType, String value)
throws Exception
checkRole(Topic player, Topic roleType, Association assoc)
throws Exception
In all cases above, the first first constraint to fail triggers an exception, unless a logFile was named, in which the exception data is simply dumped into it and execution continues.
|
Part 2. The Validator Data
This is all deemed accessible to the validator because of aspect Type declarations:
- checkProp() gets them from the given propType
- checkRole() gets them from the given roleType
In both cases, the data is to be found in the <resourceData> for
the above PSI, which explains what it means in formal detail.
Generally, it always handles these local constraints, defined by each aspect by using the constraints[] psi-tree:
- cardinality - min and/or max values
- domain - the type of subject or assoc
- range - format of the String or type of player
At
each usage, checkProp() logically checks the
format of its string, and the other constraints listed above against the propType expectations
The checkRole() logic
is similar, but checks the player(s) - range and cardinality -
and the assoc type (domain) against roleType expectations.
No declared data type in the aspect means no constraints are
implied. Part 3 covers a planned range-specific expansion for
open value constraints which can also be checked by the above method calls.
|
Part 3. Directions for the Future
1) A checkRole() call might also check global association issues
such as unexpected or missing roleTypes, provided a data type for the
association itself somehow exposed these constraints. This is expected to be defined as part of the Situation type
2) Valid association roles with no rolePlayer yet assigned could also be checked.
They may not be errors in WORDS, as one major motivation for scripts
is letting rolePlayers be instantiated only when forced by a related query. But the presence of
the needed default scripts could be checked, and perhaps their format.
3) Expansion of both checkRole() and checkProp() can be done incrementally by supporting additional range-specific value constraints, in any convenient order, as each becomes defined. This requires the addition of related compiled code for property predicates or topical predicates, each of which has a similar signature and throws an exception if its embedded checks fail to pass.
4) Limitation of the validator algorithm to check only a
portion of the
Topic Map, such as those topics and associations changed in the
most recent input paragraph to WORDS. This must be done before
the next paragraph is processed. Ideally, it will occur as soon
as possible, incrementally,
before the final parsing of each contained grammar form. At that
level of granularity,
constraints that fail will signal the parser that the analysis
path being used is suspect, and thereby help to direct it away from
semantically invalid analyses of
the text.
5) TMCL compatibility
will be maintained whenever possible, as it becomes formally
defined The expansion approach outlined in (3) is meant to
facilitate this. The requirements in (4) limit this, however, as
TMCL yet makes no commitment to support low granularity or incremental
validation, nor to validate soon enough or swiftly enough to be useful
in WORDS early releases.
|