P4V14 - Section 2

Ensuring the Correctness of Transmittals

First and foremost, a transmittal is required to pass both syntax_checker and rules_checker to have any possibility of being considered valid. The syntax_checker application tests that the transmittal is compliant with SEDRIS syntax, while rules_checker, given a transmittal that has already passed syntax_checker, tests for compliance with some of the formal semantic constraints of SEDRIS. Please note that the results of rules_checker presuppose that the transmittal has passed syntax_checker; rules_checker does not check for the syntactic validity ensured by syntax_checker.

When producing a transmittal, please review Part 5, Volume 2 of the SEDRIS Documentation Set, Checker User's Guide, which specifies the constraints that are checked by each utility (apart from the purely syntactic requirements of a SEDRIS transmittal). If a data provider specifies data involving a constraint that is not currently checked by either application, the data provider's transmittal is still required to comply with that constraint in order to be considered valid.

2.2

Providing Useful Meta-Information

2.2.1	Overview
	Certain optional information can be supplied within a transmittal that will make it more useful to the consumer; in some cases, it can reduce the size of the data provider's transmittal as well.

2.2.2	Summary Information
	To produce a valid transmittal, a data provider is required to supply at least a sketchy summary of its contents via the <Transmittal Summary> component of the <Transmittal Root>. To assist the consumer of the data, however, it is recommended that data providers convey some of their a priori knowledge of their transmittals' structure by providing more than the required minimum of summary information. We will begin by discussing the required minimum. The fields of the <Transmittal Summary> instance of a transmittal should be set to their final values by the data provider once the entire content of the transmittal has been provided. Recall that the fields of a <Transmittal Summary> instance can be edited after the object has been created, and even after components have been added, if desired. The models_present, images_present, sounds_present, and symbols_present field values of a <Transmittal Summary> should all be false unless the <Transmittal Root> has components matching the corresponding <Library> subclasses. Please note that the colours_present flag does not indicate merely the presence of a <Colour Table Library>, but the presence or absence of any <Colour> instances anywhere in the transmittal. Recommended practice is that a data provider keep track of what classes of objects have been added to a transmittal while it is being produced, and when the information is complete, use this information to generate an appropriate list of <DRM Class Summary Item> components for the <Transmittal Summary>. Note that for classes that specify spatial reference frames, such as <Environment Root> and <Property Grid>, the data provider should in addition specify complete lists of <SRF Summary> instances for the <DRM Class Summary Item> instances corresponding to those classes, specifying the spatial reference frames in use in the transmittal. A further recommended practice involves the EDCS_usage_list_is_comprehensive flag of <Transmittal Summary>. If a data provider does not use any EDCS Attribute Codes or EDCS Classification Codes in the transmittal, this flag shall be set to SE_FALSE. For data providers who use EDCS, however, it is recommended (though not required) that such a summary be provided via the optional <EDCS Use Summary Item> components of <Transmittal Summary>. If, in such a summary, every EDCS Attribute Code used in the transmittal has a corresponding <EDCS Use Summary Item> containing an appropriate <Property Description>, and every EDCS Classification Code used in the transmittal has a corresponding <EDCS Use Summary Item> containing an appropriate <Classification Data> (qualified if the ECC is qualified), then the usage list may be considered comprehensive. For <Environment Root> instances and for <Models> with complex structures, data providers are advised to provide hierarchy summary information via appropriate <Hierarchy Summary Item> lists. Additional context-specific summaries of DRM class usage and EDCS usage can be provided at various levels of a hierarchy summary, if desired.

2.2.3	<Data Table>s
	In the case of <Data Table> instances, a data provider may include <Property Characteristic> components for the <Table Property Description> instances to specify minimum value, maximum value, measurement error, and other information about the data set represented by that slice of the table. In addition to being useful to the consumer of the data, such information can be used by the SEDRIS API to compress <Data Table> instances when they are stored in the SEDRIS Transmittal Format.

2.3

<Data Table>s

The previous section discussed the metadata aspects of working with <Data Table> instances.

An even more important consideration comes into play when a data provider wishes to edit a <Data Table>. While the individual cell data within a table can be manipulated, once the signature of the table has been specified and cell data has been initially added, a data provider cannot modify the signature of the existing table. Currently forbidden operations include: changing the field values of the <Axis> and <Table Property Description> components; removing <Axis> or <Table Property Description> components; and adding <Axis> or <Table Property Description> components. Some of these restrictions may be lifted in future releases of the SEDRIS API, but they are in force until further notice. Note that the API itself will not always stop a user from performing such an operation; it is the user's responsibility not to attempt to invalidate the structure of his or her <Data Table> during an edit operation.