Neutral file

OPP scientists evaluated PDF submissions and supplemental files. For a pilot electronic data submission, OPP discussed the content of supplemental files with the registrant interested in providing an electronic data submission and worked on the data fields of interest for several toxicology studies. OPP evaluated SAS-XPORT (SAS Transport) files as a neutral file format for data tables. Two programs were evaluated by OPP DBMA Copy and Stat Transfer, which will transfer the data from the SAS-XPORT format into a format usable by the reviewer. 

The Neutral File format is conqirised of a computer file, records, groips, and fields of data A sanqile file fmmat is shown below. 

CENTRIFUGAL PUMP NEUTRAL FILE EXCHANGE VERSION 1.0 BEGIN HEADER DATA — File Header Data here see spedfication ... 

All document types including more complex ones such as integrated batch documentation, illustrated SOPs. All document types must be stored in a neutral file format. 

In fact, suitable interfaces are necessary for software communication, since the disciplines involved use different applications. Besides, neutral data formats such as STEP AP 214 (ISO 10303) are required due to the fact that the different software components involved often create proprietary file formats. A neutral file format can ease information exchange between many applications, because it helps avoiding bidirectional conversions. 

Mentor Graphics Neutral File. Several nonstandard netlist formats can be output by various CAD software suites. AU such formats contain connection point records and their grouping into nets. American designers and fabricators occasionally used a stripped-down version of the Mentor CAD format Neutral File to transfer netlist information, and thus it is described here. 

The Mentor Graphics Board Station Fablink application produced the Mentor Graphics Neutral File format. It has several sections, each describing one aspect of a board (components, netlist, holes, etc.). 

A full neutral file contains these information sections ... 

FIGURE 18.14 An excerpt from a Mentor Neutral File. Section names and records roles are pretty obvious, because clear key words are used. The number sign,, denotes a comment. 

Appendix D. A neutral file for fixed format letters. 225... 

Relationships between neutral file and data base. 6... 

Develop a neutral file format for transfer of CAD data (curves, surfaces, and solid models) between CAD systems, and from the CAD domain to CAA (computer aided analysis) and CAM (computer aided manufacturing). 

Develop pre- and post-processors with a number of representative CAD systems for this neutral file format. 

Contribute to the standardization activities in the national standardization bodies and in ISO for the establishment of a neutral file format for CAD data. 

In Figure 1 the first row of boxes indicates the overall concepts which the user must keep in mind an interface implemented as a pair of pre- and post-processors performs the translation between the product data representations in CAD systems and the neutral file. The second row represents the formal specification contained in this book the neutral file grammar which is specified in BNF productions, the semantical interpretation of a neutral file (defined as a finite state machine) in order to build a data structure which is compatible with the reference model specified. The last row shall indicate that validity of a neutral file requires conformance with the grammar, validity of the post-processor requires conformance with the semantic specification, and finally that CAD system data base contents can... 

It was stated that there is a need to understand the contents of a CAD data base. However, the contents of a particular data base may only reflect, for example, the input of the user in creating a particular model. In the case of high level representation schemes, such as used in constructive solid geometry (CSG) modelers, this is a suitable method of transferring the information. This is not always the case, however, since many geometric model data bases contain purely geometric and other associated information. The point to be made here is that the neutral transfer mechanism must cater not only for high level representations, but also the very lowest level of data. A further point to be made is that the neutral file is not a copy of a particular data base. It contains all the relevant data in such a way that here is no loss of information. 

The neutral file represents an intermediate stage of mapping one data base onto another. In that process, it is clearly necessary to map from a data base onto the neutral file, and from the neutral file onto other data bases. Clearly only two interfaces are required for a given system in order to achieve this. The consequences of this are that the processors must be very robust, and that, although the neutral file must be wide ranging enough to cope with as many systems as possible, it should also force any particular implementation to map onto the neutral schema. 

A problem with some existing standards has been that implementors have used only parts of those specifications which suit their particular needs. The result is that the neutral file ceases to be a useful general transfer mechanism, since any other system interpreting files generated by such an implementation will have to provide extensive conversion facilities, thereby destroying the purpose of the neutral file. Clearly no single system will have a full implementation of the neutral schema, therefore, well defined subsets (implementation levels) of that schema need to be stated in the specification (this technique has been used successfully in the specification of the graphical kernel system GKS). 

This chapter describes the overall concepts underlying the specification of a neutral file for exchange of GAD models between CAD systems or a CAD system and other application areas. 

On the physical layer, however, due to the requirements of sequentialising the neutral file, the referencing mechanism is restricted (see The Physical Level on page 15). 

Most references in a world (neutral file) will be internal, that is to entities that are transferred on the same file. However, a complete product description often includes a number of individual database files as well as components taken from part libraries. In order to cater for this, "external" references are allowed to entities not transferred on the same file, but which are assumed to reside already in the receiving environment. User-defined names provide the basic means for passing external references. In addition, a special mechanism is provided for referencing entities in part libraries. These references will not be resolved until receiving system starts working with the world it has received. 

The physical layer represents a strictly sequential process that can build up the CAD data structure in the receiving system from a single parse of the neutral file. The consequence of this principle is that no forward references are allowed on the file. The reason for this principle is two-fold. 

The file format supports the block structure that corresponds to the scope aspect of entities. The purpose of the block structure is to localize, on the file, all information which fully defines a certain entity. An effect of such localization is that the post processor, having found the end of the definition of an entity, may forget all information that was used to build up this entity. This principle allows minimisation of temporary data storage and data management that has to be performed by the post-processor. A second effect of this principle is that, in situations which require interpretation of only part of the neutral file, there is an obvious indication on the file where to start and to end with each entity. No search for information before the start or after the end is needed in order to completely define this entity. 

All CAD I neutral file follow the envelope concept. The beginning and the end of the neutral file is clearly marked inside a larger CAD I metafile. The metafile may carry additional information such as letters, FORTRAN source code, even CAD information according to some other standard such as IGES, VDA-FS, or SET. No conflict arises between these different files even when they are transported as one sequential file on magnetic tape or computer network. 

Structure attributes (parameters) of type INTEGER have integers as values. The regular set integer (see Tokens of the neutral file language on page 160) formally defines the set of INTEGER constants. 

---