| |
File Header Structure |
| <<< File Handling | Chapters | Graphical Output >>> |
There is a standard format for a Frustrum file header, designed to give the following benefits:
All files must begin with a file header. The header is written and read by the customer’s implementation of the Frustrum, not by Parasolid. The reason for standardizing the format of the header is to ensure compatibility between different Frustrum implementations; Parasolid itself never sees the header and therefore has no knowledge of its format.
It is vital that every Frustrum implementation produces file headers which conform to the standard. Therefore, the Frustrum validation tests include specific checks that this is the case.
The file header consists of a preamble, three parts of keyword data and a trailer.
The preamble is written as two lines of 80 characters, each terminated by an end of line character. It includes all characters in the ASCII printing set.
**ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz************************** **PARASOLID !"#$%&´()*+,-./:;<=>?@[\]^_`{|}~0123456789************************** |
The punctuation characters in the preamble are written in the same order as they appear in the ASCII sequence (excluding alphanumeric characters).
Each of the three parts of keyword data starts with the declaration “**PART1;”, “**PART2;” or “**PART3;”. (The quotation marks used here are for documentation purposes and do not appear in the file.)
Each part declaration is followed by a sequence of keyword definitions, each consisting of a keyword name and a keyword value.
The keyword definition sequence for each part is terminated by the start of the declaration for the next part or by the start of the trailer record.
Keyword definitions are written to file so that no output line is more than 80 characters long. The new line characters which are required to achieve this layout have no effect on the meaning of the keyword names or values and can appear anywhere within a keyword definition as it is written to file.
A new line character is written at the end of each keyword definition sequence so that the next part declaration or trailer record starts on a new line.
The part 1 data is standard information which should be accessible to the Frustrum (e.g. by operating system calls). It is the responsibility of the Frustrum to gather the relevant information and to format it as described in this specification. A list of keywords and their meanings is given in a later section.
The part 2 data is again standard information, but this time is information not readily available to the Frustrum (e.g. the Parasolid schema version), and which therefore must be provided from Parasolid. When creating a new file, Parasolid passes a string containing the relevant keywords/values to FFOPWR or UCOPWR, as appropriate. The frustrum must then insert this string into the header in the appropriate place.
The string passed to FFOPWR or UCOPWR does NOT include newline characters or the “**PART2;” prefix; these must be added by the Frustrum. However, the Frustrum should not add escape characters to the string; these have been added by Parasolid, if required.
As an example, the string passed to FFOPWR for the following sample file header would be “SCH=SCH_700084_7007;USFLD_SIZE=0;”.
The part 3 data is non-standard information, which is only comprehensible to the Frustrum which wrote it. However, other Frustrum implementations must be able to parse it (in order to reach the end of the header), and it should therefore conform to the same keyword/value syntax as for part 1 and part 2 data. However, the choice and interpretation of keywords for the part 3 data is entirely at the discretion of the Frustrum which is writing the header.
All keyword definitions which appear in the three parts of data are written in the form
<name>=<value>
e.g.
MC=hppa;MC_MODEL=9000/710
;
Escape sequences provide a way of being able to use the full (7 bit) set of ASCII printing characters and the new line character within keyword values.
The implementation must also be able to recognise and to convert escaped characters as they are read back from file.
The requirement to format the output data into lines of 80 characters or less means that new line characters are ignored as keyword definitions are read back from file (although they are still significant when they are read as part of the preamble or the trailer record).
If new line characters need to be included within a keyword value, they must be written to file in escaped form as “^n” (up_arrow followed by lower case n).
Care is required when reading keyword values from file so that new lines which are part of the keyword value are not confused with file layout new lines.
The specification does not allow spaces to be written to file as part of the keyword data. This is because of the danger of losing trailing spaces when porting text files between different systems.
If space characters need to be included within a keyword value, they must be written to file in escaped form as “^_” (up_arrow followed by underscore).
The specification uses the semicolon character to mark the end of a keyword value. If semicolon characters need to be included within a keyword value, they must be written to file in escaped form as “^;” (up_arrow followed by semicolon).
Care is required when reading these characters back from file so that the semicolons within a keyword value are not confused with the semicolons which terminate a keyword value.
The specification uses the up arrow character as its escape character when writing keyword values to file. When used in a keyword value, the up arrow character is doubled up when it is written to file so as to avoid ambiguity when reading back the data.
The two character escape sequences may be split by a new line character as they are written to file. They must not cause any output lines to be longer than 80 characters.
Only those characters which belong to the ASCII (7 bit) printing sequence, plus the new line character, can be included as part of a keyword value.
It is possible that the space, semicolon and up arrow characters are used within keyword values which follow the KEY and FILE keywords in part 1 data; the implementation must be able to decode these, even if it does not need to encode escaped characters when writing its own file headers.
The new line character does not appear as part of a file or key name (in normal operation) as this is rejected by the PK argument checking phase.
It is possible for any of the escaped sequences to be used within the keyword values which are associated with part 3 data.
Note that the preamble and the trailer record are written to file in literal mode, without using escape character sequences.
The following keyword names must be present in each file header, in the correct section of part data. The keyword name must be set to one of the associated values which is shown on the right hand side below (such as hppa) or must use the formatting conventions which are given (such as the date consisting of a one or two digit day number, a three letter abbreviation for the month in lower case and a four digit year number).
The pre-defined sets of keyword values are written in lower case rather than in upper case; this is significant.
The spacing and commas which are shown with the lists of pre-defined keywords are for documentation purposes only and must not be used in keyword values.
The sequence “...” is used to represent an arbitrary sequence of one or more characters (for example, the value for the keyword FILE can be cube.xmt_txt). However, all characters which are used in a keyword value must be converted to the escaped form where necessary.
If the Frustrum developer cannot determine which keyword value applies to a particular keyword, in certain cases this can be set as “unknown”. In all other cases, the value should be set to one of the pre-defined values or to use the specified format.
If the range of keyword values which is shown in the Frustrum documentation is not sufficient (e.g. Parasolid is ported to a new machine), a request should be made to Parasolid Support to have the list extended.
|
Frustrum supplier and implementation name e.g. sdl_parasolid_customer_support |
||
|
application which is using Parasolid e.g. parasolid_acceptance_tests |
||
There are no restrictions on the choice of keyword names and values which can be used in the part three data, other than the general rules which have been stated earlier.
| <<< File Handling | Chapters | Graphical Output >>> |