| |
Logical Layout |
| <<< About This Manual | Chapters | Physical Layout >>> |
The logical layout of the XT data is as follows:
PK_PART_ask_kernel_version
.|
Note: Applications writing XT data using information from this version of the documentation should use version 3400000 and schema number 34000. |
Each node entry begins with the node type. If the node is of variable length (see below), this is followed by the length of the variable field. The index of the node is then output, followed by the fields of the node. If the XT data contains user fields, and the node is visible at the PK interface, then the fields are followed by the user field, in integers.
The terminator which follows the sequence of nodes is a two-byte integer with value 1, followed by an index with value 0. The index is output as ‘0’ in a text file, and as a 2-byte integer with value 1 in a binary XT data.
The node with index 1 is the root node of the XT data as follows:
XT permanent structures are defined in a special language akin to C which generates the appropriate files for a C compiler, the runtime information used by the Parasolid Kernel, along with aschema file used during transmit and receive. For example, the schema file for version 31.0 is named sch_31000 and is distributed with the Parasolid Kernel.It is not necessary to have a copy of this file to understand the XT data format.
For each node type, the schema file has a node specifier of the form;
<nodetype> <nodename>; <description>; <transmit 1/0> <no. of fields> <variable 1/0> |
This is followed by a list of field specifiers which say what fields, and in what order, occur in the XT data.
Field specifiers have the format:
<fieldname>; <type>; <transmit 1/0> <node class> <n_elements> |
Nodes and fields with a transmit flag of zero are ephemeral information not written to XT data. Only pointer fields have non-zero node class, in which case it specifies the set of node types to which this field is allowed to point. The element count is interpreted as follows:
|
Note: In the schema file, fins are referred to as ‘half edges’, and groups are referred to as ‘features’. These are internal names not used elsewhere in this document. |
When reading XT parts, partitions, or deltas, the Parasolid Kernel converts any data that it encounters from older versions of the Parasolid Kernel to the current format using a mixture of automatic table conversion (driven by the appropriate Schemas), and explicit code for more complex algorithms.
However, backwards compatibility of file information - that is, reading data created by a newer version of the Parasolid Kernel into an application (such as data created by a subcontractor) - can never be guaranteed to work using this method, because the older version does not contain any special-case conversion code.
From Parasolid V14 onwards, XT parts, partitions and deltas can be transmitted with extra information that is intended to replace the schema normally loaded to describe the data layout. This information contains the differences between its schema and a defined base schema (currently V13's SCH_13006).
This enables XT parts, partitions, and deltas to be successfully read into older versions of Parasolid without loss of information.
The only fields that are included in this information are those which can be referenced in a cut-down version of the schema pertaining only to the XT part data that is transmitted. Specifically, a full schema definition can contain fields that are not relevant in the context of the transmitted data (fields relating to snapshots, for example), and these fields are excluded.
Fields that are included are referred to as effective fields, and are either transmittable (
xmt_code == 1
) or have variable-length (
n_elts == 1
).
Most of the XT data are composed of integers, logical flags, and strings, but are of restricted ranges and so transmitted specially in binary format. The binary representation is given in bold type, such as “integer ( byte)”. This is only relevant to applications that attempt to read or write XT data directly rather than via a Parasolid image. Two important elements are;
Presence of the new format is indicated by a change to the standard header: the archive name is extended by the number of the base schema, e.g., SCH_1400068_14000_13006, and then the maximum number of node types is inserted ( short).
Transmission then continues as normal, except that when transmitting the first node of any particular type, extra information is inserted between the nodetype and the variable-length, index data as follows:
|
The field type. Allowed values are described in “Field types”, below. Omitted if |
||
name
,
xmt_code, ptr_class, n_elts
and
type
) then output the flag value 255 (byte0xff).
For text data in XT formats
PK_transmit_format_text_c
and
PK_transmit_format_xml_c
, a new escape sequence is defined: the 2-character sequence \9 denotes a sequence of nine spaces. At V14 of the Parasolid Kernel, this applies to attribute definition names, field names, and attribute strings.
The XT format is not itself a binary protocol, and so does not define data sizes; the only requirement is that a runtime implementation has sufficient room for the information. The available implementations run with 8bit ASCII characters, 8bit unsigned bytes (0..255), 16bit short integers (0..65535 or -32768..32767), 32bit integers (0..4G-1, -2G..2G-1) and IEEE reals. The implementation used in a given binary XT data is specified by the "PS<code>" at the start of the file. See Chapter 3, “Physical Layout”, for more information.
The full list of field types used in XT data is as follows:
As an example, consider a POINT; its formal description is as follows;
Its corresponding schema data entry is as follows;
29 POINT; Point; 1 6 0 node_id; d; 1 0 0 attributes_features; p; 1 1019 0 owner; p; 1 1011 0 next; p; 1 29 0 previous; p; 1 29 0 pvec; v; 1 0 0 |
In the above example, the
attributes_features
field must be of class
ATTRIB_FEAT_cl
, the owner must be of class
POINT_OWNER_cl
, and the next and previous fields must refer to points. A full list of node types and node classes is given at the end of the document.
Each node class corresponds to a union of pointers given in the Schema Definition section.
Variable-length nodes differ from fixed-length nodes in that their last field is of variable length, i.e. different nodes of the same type may have different lengths. In the schema the length is notionally given as 1, e.g.
struct REAL_VALUES_s // Real values { double values[1]; // $f[] }; |
Its schema file entry would be as follows;
83 REAL_VALUES; Real values; 1 1 1 values; f; 1 0 1 |
The number of entries in each such node is indicated by an integer in the XT data between its nodetype and index, so an example might be
83 3 15 1 2 3 |
In some cases a node will contain an index field which does not correspond to a node in the XT data, in this case the index is to be interpreted as zero.
Here is a reformatted text example of a sheet circle with a color attribute on its single edge:
| <<< About This Manual | Chapters | Physical Layout >>> |