ISO 10303-21:2016(E)

Annex A
(normative)

File representation on storage media

A.1 Record-oriented transport content

A magnetic tape may contain several data sets. Each data set may be a sequential file whose content can be interpreted as an exchange structure conforming to this part of ISO 10303.

It is the responsibility of the sender of such a tape to communicate to any receiver, either on the tape or otherwise, information on which data sets are exchange structures conforming to this part of ISO 10303.

The transport format for each exchange structure is as follows:

A.1.1 Transport format for magnetic tape media

For tape transport of exchange files, the following characteristics defined in ISO/IEC 3788 define the preferred format for interchange:

Other standard magnetic tape media, such as 246 cpmm (6250 bpi), may also be used.

A.1.2 Other storage media with record-oriented storage

Other media on which exchange structures are stored as sequences of records may use the same transport format as specified for tapes.

A.2 Line-oriented transport content

Some magnetic media contain data sets stored as a sequence of lines. Each of these data sets may be a sequential file whose content can be interpreted as a file conforming to this part of ISO 10303.

The file shall consist of a sequence of lines:

The means by which lines are delimited and end-of-file is represented are dependent on the operating system and are a matter of agreement between sender and receiver, subject to the restriction that the delimiters shall not make use of any character in the basic alphabet. Whatever their representation, line- and file-delimiters shall be ignored when processing the exchange structure.

A.2.1 Transport format for diskette media

Any of the popular media for diskettes (3 1/2", 5 1/4", low or high density) may be used to transmit the exchange structure.

It is the responsibility of the sender of such a diskette to communicate to any receiver either on the diskette or outside the diskette which data sets are exchange structures adhering to this part of ISO 10303.

A.2.2 Other media

Other media on which files are stored as sequences of lines may use the same transport format as specified for diskettes. In particular, this format may be appropriate for transfer over communication networks (E-mail).

NOTE 1      During transfer of clear text files via electronic mail attachment, lines that start with full stop are sometimes corrupted by either removal or doubling of the full stop. Electronic mail transfer may wrap lines in clear text attachments, so removal or doubling has also been observed with full stop appearing later in long lines.

NOTE 2      Implementations are advised to use line breaks within the exchange structure to avoid placing a full stop as the first character and to wrap lines containing full stop so they do not extend beyond 80 characters. Placing the exchange structure in a ZIP archive as described in A.4 also avoids the problem, because ZIP files are typically handled differently when sent as electronic mail attachments.

A.3 Treatment of multi-volume files

It may be necessary to spread an exchange structure over more than one physical volume.

NOTE      Depending on circumstances, special administrative software or the operating system of the receiving system may concatenate the physically separate parts of a multi-volume file into one exchange structure.

A.4 Transport for compressed archive content

A file that meets the requirements of this specification may be compressed and stored in a ZIP archive (see 3.1.6). The archive shall be written using PKZip 2.04g compression.

NOTE 1      This compression method limits the zip support to exclude encryption, Unicode filename support and usage of deflate64 mechanism. This compression is compatible with Windows Compressed Folders, WinZip, info-zip and zlib.

A ZIP archive may contain multiple compressed files. Some of these files may be exchange structures that meet the requirements of this specification. Some of the files may be subdirectories containing further files. Some of the files may themselves be ZIP archives. Finally some of the files may be ancillary data that is not part of the information model but is being carried with the model so that it can be referenced.

If a URI resolves to a compressed archive then a root file in the archive shall be read into the application. This file shall be an exchange structure that meets the constraints of this part of ISO 10303. This file shall have the name "ISO-10303.p21".

NOTE 2      The transport protocol (for example http, ftp, file etc.,) delivers a file to the requestor. If this file is ASCII then it is processed as an exchange structure. If the file is binary then the decompression algorithm is applied and the file named "ISO-10303.p21" is processed as an exchange structure.

The "ISO-10303.p21" file shall be known as the root. Any other files in the archive, including any files in sub-directories, shall be known as subsidiaries. An archive shall be conformant to this part of ISO 10303 only if it contains a root.

The root file shall be known by its local name if referenced by other files inside the archive and by the name of the archive when referenced from outside. In order for references within the archive to be kept consistent, all relative addresses shall be interpreted as addresses relative to the location of the referencing file within the archive directory. No relative address shall address a file outside the archive.

NOTE 3      Because all relative addressing is kept in scope an implementation may read the zip file and uncompress it in a location of its choosing for subsequent processing.

Only the root file can be referenced from outside of the archive. If other files in the archive contain entities that need to be externally referenced then an anchor must be defined in the root file and that anchor must forward the reference to the required entity or value in the subsidiary file.

EXAMPLE 1      An archive is created for a building. The root file describes the building. The subsidiary files describe the two floors and a picture.

File name Content summary
ISO-10303.p21 Project header data
first_floor.ifc Description of the first floor
second_floor.ifc Description of the second floor
picture.jpeg Photograph of the building

EXAMPLE 2      Anchor section of the ISO-10303.p21 file exposes archive anchors to external applications:


ANCHOR;
<first_floor> = #10				/* first floor defined in another file (see references) */
<second_floor> = #20				/* second floor defined in another file (see references) */
<electrical_system> = #30			/* electrical system defined in data section */
<building_photo> = <picture.jpeg>		/* extra- data not part of information model - but made accessible */
ENDSEC;

EXAMPLE 3      Reference section of the ISO-10303.p21 file:


REFERENCE;
#10 = <first.ifc#51c13346-2084-4494-8003-d956d1d25c45>		/* GUID that anchors an entity in first.ifc */
#20 = <second.ifc#cdd73fcb-e2d1-4546-b4f2-c34d2d333d42>		/* GUID that anchors an entity in second.ifc */
ENDSEC;

A.5 Transport for directory content

In order for the addressing to be consistent for structures that may be in an archive at some times, and outside an archive at other times, the transport for compressed content rules shall also apply if a URI resolves to a directory containing the file named "ISO-10303.p21".

© ISO 2016 — All rights reserved