- From: Al Gilman <asgilman@iamdigex.net>
- Date: Mon, 04 Dec 2000 19:55:52 -0500
- To: w3c-wai-er-ig@w3.org
As my contribution to formalizing the discussion today, I wish to offer the following template for a unit evaluation record. A composite evaluation record is an infoset containing one or more of these. [Properties of the whole evaluation record, c.f. external view of an object, interface of a VHDL entity, etc.:] applicationOf: ref[preferrablyByURI](testDefinition) whoSez: ref["](agentOrAuthority) [Note: there may be a nodeID and other stuff, but in this model that is handled by multiple inheritance. If the testRecord is embedded in an XML document, then there are properties of the node that go with the XML host environment. These are just the ones that go with the test record application.] [Properties by parts, body of the test evaluation record] testInstanceInfo:includeByRefinement(testDefinition.instanceInfoProfile) containing( forEach(testDefinition.instanceInfoProfile.contentUnderTestFormalReference) includeByReference( testDefinition.instanceInfoProfile.contentUnderTestActualReference ) forEach( testDefinition.instanceInfoProfile.evaluationResultFormalReference ) includeByValue(testDefinition.instanceInfoProfile.evaluationResultActualRefe rence) ) That's it. A transaction record is in form similar to the detailed pass-by-<mode> semantics of a subprogram call transaction; but with pass-by-<mode> replaced with retain-by-<mode>. A unit evaluation criterion has an information interface much like the call and return information profile of a subprogram. It is a transaction typespec. The test definition has a generic/specific relationship to each of its associated test applications. Al
Received on Monday, 4 December 2000 19:20:31 UTC