| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
As Tim points out in the General Discussion, although I would not use the term information model, it is imperative that we have some overarching description that allows the various schemas to use items such as Test, ResultsSet, TestGroup consistently across the whole ATML.
I believe that place to be the ATML 1671 document - thought of as the ATML Framework or Overview document.
Today we could have the situation where TestResults can define structured/hierarchical results which can not be generated from TestDescription and where the Tests may not be usable in Diagnostics. A situation I know we'll work towards eliminating. Having said that I see within ATML an element of evolvement, not only of the various schemas, but also of the information through its life time as an XML document. I can see a situation were there exists a valid XML TestResults document that can not be used for diagnostics, because the relevant 'processing' has not taken place. After such processing new information is added that completes the definition and allows the TestResults to be 'fully diagnostic formed'. That does not mean that they are not the same item, just that they have not yet reached a level of maturity -- "Do not sent a boy to do a man job".
Although I wound not want to have all the schemas defined before we attempt such a normalisation process, equally I feel that trying to tightly pin down the elements prior to any component development would be equally difficult. What I see happening is that these key elements will come out of the ATML Architecture, and that each of the ATML components will identify how they differ from the common ideal. These difference then are the items that we capture in the service descriptions, to ensure you can only pass a 'fully diagnostic formed' test to a diagnostic service, while still being able to define a test that has no conclusion or Outcome.
This would imply some impetus to complete the ATML 1671 first draft scheduled for the Jan face-2-face meeting
While there may be answers for the particular examples that Jeff raises, in general, it is extremely important to describe several levels of semantics that are present, some of them implicit, in XML Schemas. Jeff's concern about adwequate support for constraint representation is absolutely valid, even though the immediate examples may be refuted. There are other more subtle and equally imnportant issues, however. While XML Schemas do a good job of expressing elementary data types and constraints, they do not supply more general and equally important (implicit) semantics that are necessary for understanding the intent of the modeler.
Implicit Semantics
refer to our mental models of some domain of interest. What may seem to be simple concepts can have surprisingly different interpretations. For example, in the mind of an instrumentation engineer, the notion of a test may relate to the application of stimuli and measurement of response in an attempt to ascertain the state of some physical property of the system. To a developer of analytical diagnostic software applications, however, the same notional concept may relate to a more abstract concept of an event with an outcome, associated with some confidence value, which can be used in combination with other like events to determine a system diagnosis or trend.What makes semantic integration a challenge is two-fold: first, the representation of information and the information itself are often bound tightly together; and second, that information frequently lacks context. Developers often think not of the data itself but rather the required structure of the data: schemas, data types, relational database constructs, file formats, and so forth - structures that don't pertain directly to the information at hand, but rather their assumption of what the data should look like and the mechanics of operating upon that data. In tightly coupled architectures, descriptive data structures are themselves sufficient, since they provide systems a mechanized way of coping with the information they are being fed. However, a precise semantic definition is required for applications to detect inconsistencies and inaccuracies in information that is shared across loosely coupled integration boundaries in order to eliminate ambiguity in information requirements.
The semantics of XML schemata and documents are again accessible only in written specifications - the schema represents data types and constraints and (hopefully adequates) English definitions and explanations can be provided in support of the schema representation . XML schema definitions provide strong data typing, simple constraints, and "implicit" subsumption ("implicit" because, although element types can be extended to utilize characteristics of related elements, there is no "explicit" class hierarchy). While XML has rapidly become the lingua franca of electronic commerce, the semantics of that information is still largely defined at the application interface layer only and any agreement between applications as to the common meaning of those semantics can only be shared by ad hoc means. Put more succinctly, neither XML nor XML Schema representations are suitable for generalized semantic exchange without an explicit agreement among users of the representation as to the precise semantics intended in the representation.
Another consideration that we have never discussed is the integration of the various ATML schema to produce a coherent view of the ATML information domain. While we are developing each of these XML schemas to reflect a particular purpose, how do they relate to each other?
Is the notion of test or outcome in test Results the same as that in the Reasoner or Test Description Schemas?
Does the term failure meant the same thing in one schema as in another?
If I need information from multiple scjhemas to fulfill my information needs, what do I use as a key to relate the multiple schemata?
The only way to answer these questions is to create an overarching information model that integrates the various schemata into a coher3ent view that relates the information in one to another. he various schemata then become simply valid partitions of the ATML information domain, and the semantics can be interpreted as a whole rather than as disjointed and possibly quite confusing separate entities.
Tim W