Electronic Parts Catalog Exchange Standard | Specification

Release 1.0, February 27, 1996

Distributed by the Subcommittee on Information Standards
Rail Industry Forum
27 February 1996

  1. EPCES Technical Specifications
    1. SGML
    2. CGM Version 3
    3. TIFF 6.0
    4. HyTime
    5. ATA 2100 GRExchange
    6. Automated Interchange of Technical Information
  2. Document Object Classes
    1. Images
      1. Bi-Tonal
      2. Grayscale and Color
    2. Drawings
    3. Narrative Text
      1. Front Matter
        1. General catalog identification
        2. Introduction Section
        3. Alphabetical/Numerical Index, Table of Contents
        4. Effectivity Cross Reference Information
        5. List of Vendor’s Code, Name, Address, Phone Number
        6. List of Abbreviations
        7. List of Definitions
      2. Body Text
        1. Associated Text
        2. Supporting Table
    4. Data
      1. Part Information
      2. Drawing Data
      3. Effectivity
      4. Physical Part Characteristics
    5. Revision Control
    6. Links
      1. HyTime Links
        1. Grid and Graphic Definitions
        2. Graphic Hot Spot
        3. Translation of Graphic Hot Spot to EPCES Grid
        4. Example
      2. DTD Navigational “Links”
      3. SGML ID/IDREF “Links”
  3. Media Exchange – MIL-STD-1840B
    1. Media Options
    2. EPCES Packaging
    3. SGML Document Transfer Unit
      1. Transfer Unit Declaration File
      2. Document Type Declaration File
      3. Transfer Unit Data Files
        1. SGML Coded Text Source File(s)
        2. Illustration file(s) in CGM or TIFF format
        3. Supported Optional Files
    4. File Naming
    5. Header Records
    6. Media Labeling
RIF-EPC DTD (Appendix A)
SGML Declaration  RIF-EPC DTD  DTD Tree Structure 

SGML Element Description (Appendix B)

  1. EPCES Technical Specifications
    1. SGML
      Function: Defining all information elements in the EPCES
      Specification: MIL-HDBK-SGML – Application of MIL-M-28001 Using Standard Generalized Markup Language ISO 8879-1986 – Information Processing – Text and office systems – Standard Generalized Markup Language
      EPCES Restrictions: None
      Documentation Source: American National Standards Institute  11 West 42nd Street, 13th Floor  NY, NY 10036
    2. CGM Version 3
      Function: Metafile for the storage and transfer of picture description information.
      Specification: ISO/IEC 8632:1992 — Information technology — Computer Graphics Metafile
      EPCES Restrictions: See Section 3.5
      Documentation Source: International Organization for Standardization 11 West 42nd Street, 13th Floor  NY, NY 10036
    3. TIFF 6.0
      Function: Specification for raster bi-tonal images
      Specification: ATA/2100 GRExchange 2.2 (TIFF profile)
      EPCES Restrictions: None
      Documentation Source: Aldus Developers Desk, Aldus Corporation 411 First Ave, South,  Seattle, WA 98104-2871 (206) 628-6593
    4. HyTime
      Function: Hypertext linking
      Specification: ISO 10744
      EPCES Restrictions: Utilized only where linking required to or from a “call-out” on a graphic
      Documentation Source: International Organization for Standardization 11 West 42nd Street, 13th Floor NY, NY 10036
    5. ATA 2100 GRExchange
      Function: For graphics exchanges
      Specification: ATA/2100 GRExchange 2.2 (est. publish 3/96)
      EPCES Restrictions: 7.2.4.2 – the ProfileID substring shall be “ProfileID:ATA GRAPHICS.GREXCHANGE/RIF”  7.2.4.13 – remove OCRB from the list, change the line before to read “permitted” instead of “recommended”, disallow any fonts beyond those in the list, and delete the final paragraph of this pro-forma item (which defines the ATA rule to be applied in the case “…if other fonts are used”).  7.2.9.1 – delete the paragraph which defines and allows the -4000 escape.
      Documentation Source: Air Transport Association 1301 Pennsylvania Ave, NW, Washington, DC 10004-1707
    6. Automated Interchange of Technical Information
      Function: Media and labeling specifications
      Specification: MIL-STD-1840B 3 November 1992
      EPCES Restrictions: 4.2.3.f – Formatting Output Specification (FOSI) is not defined in EPCES  5.3.2.1 – TIFF files shall be classified as “contract defined data files” using the “A” designation 5.4.2 – EPCES defines Alternative Media according to 1840C Appendix A (draft) 5.5.1 – Change “CAGE code” to “Provider code”
      Documentation Source: CALS Digital Standards Office, HQ AFMC/ENCT Wright-Patterson AFB, OH 45433-5001
  2. Document Object Classes
    1. Images
      1. Bi-Tonal The Air Transport Association (ATA) has used TIFF for the standardized interchange of raster graphics for many years in its ATA 100 and successor ATA 2100 exchange specifications. A well defined profile of TIFF 5.0 using Group IV compression was specified and developed for raster interchange. TIFF is widely implemented, especially 5.0, although apparently Group IV implementations are not so widespread. TIFF 5.0 has been superseded by TIFF 6.0, but ATA’s profile of TIFF 5.0 is still a valid 6.0 profile. (TIFF 6.0 added such features as Joint Photographic Exchange Group (JPEG) compression (which is alleged to be poorly specified) and Tiling – useful features for electronic technical documentation).Utilizing ATA’s TIFF profile with Group IV compression, the Rail Industry will be able to use commercially available TIFF 5.0 and TIFF 6.0 products for implementing EPCES.
      2. Grayscale and Color The Rail Industry is deferring the inclusion of grayscale and color exchanges in the EPCES until ATA’s specification for CGM Tile Array with JPEG is available.
    2. Drawings ATA was innovative in adopting the CGM:1992 Amendment 1 “Rules for Profiles” even before their completion, and has based its 2100 CGM profile on the Model Profile. The ATA CGM profile is the industry’s most advanced and highest quality profile, for this reason in part. This strategy has resulted in certification testing available from The National Institute for Standards and Technology (NIST). This is a critical determinant of the success of an open interchange program. Version 3 testing components should go on-line at NIST before the end of 1996.ATA has continued to develop it’s GRExchange with fixes and minor improvements, and will soon be adding JPEG compression for Version 3 raster metafiles. The main focus of ATA work now is IGExchange (Intelligent Graphics Exchange) — the utilization of Version 4 CGM to allow CGM graphics to be better integrated into hyperlinked documents.
    3. Narrative Text The Railroad Industry Forum made the distinction between “narrative text” and “data”. RIF regards narrative text as information that is ‘free-flowing’ (unstructured) text that serves as explanation or clarification of the catalog in part, or as a whole. Conversely, the notion of “data” is that of highly structured information concerning specific entities (i.e., parts) that may interface with a database or external processing system.Outside a catalog’s “front matter”, a functional parts catalogs should contain little narrative text. In an effort to minimize the ability to embed maintenance and operational information in a parts catalog, the RIF resolved to severely limit narrative text within the body of a parts catalog.
      1. Front Matter Narrative text contained in the front matter allows for general information pertinent to the catalog as a whole.
        1. General catalog identification Information concerning the catalog as a whole is captured in various elements and attributes of the root element (“rif-epc”). General Catalog identification includes the following information:
          • Original Issue Date (“rif-epc” attribute “oidate”)
          • Version Number (“rif-epc” attribute “rev”)
          • Revision Date (“rif-epc” attribute “revdate”)
          • Document Number (see “doc-nbr“)
          • Document Title (see ” titleblk“)
          • Volume Number (see ” volume-nbr“)
          • Document Provider Name and Address (see ” provider-info“)
          • Supersedure/Destroy Notices (see ” notice“)
          • Model Name/Number (see ” model-name“, ” model-nbr“)
          • General Effectivity Information (see ” effect“)
        2. Introduction Section The only portion of the catalog’s “front” section where free-flowing text can be authored is within the “intro” element of the DTD. While this “intro” is considered an Introduction, it can also be considered a “Foreword”, “How to Use”, “Abstract”, etc. This introductory section should not include information concerning effectivity (see Section 2.3.1.4), Vendor Codes (seeSection 2.3.1.5), Abbreviations used in the catalog (see Section 2.3.1.6), Alphabetical Index or Table of Contents (seeSection 2.3.1.3). The RIF-EPC DTD allows for explicit tagging of this information outside the “intro” element in an effort to provide functional capabilities to the Electronic Parts Catalog.The EPC Introduction Section consists of: (see “intro“)
          • numbered and titled paragraphs (see “topic“, “subtopic“)
          • unnumbered untitled paragraphs (paragraph text) (see “para“)
          • sequential (numbered) lists, with subordinations (see “numlist “)
          • random (bulleted) lists, with subordinations (see “unlist“)
          • tables (see “table“)
          • graphics (see “graphic“)
          • footnotes within tables and text (see “ftnote” and “ftnref“)
          • warnings, notes, and cautions (see “warning“, “caution“, “note“)
          • cross references (see “refext” and “refint“)
          • emphasized text (see “emphasis“)
          • revised text (see “revst” and “revend“)
        3. Alphabetical/Numerical Index, Table of Contents Found outside the narrative “introduction”, these sections may include opening paragraphs. However, the actual index and table of content data should not be tagged as information. For the purpose of ensuring valid index data, these portions should be automatically generated, based on the contents of the EPC, at the time of processing.(see “index-sect“, “toc-sect“)
        4. Effectivity Cross Reference Information Throughout the EPC (at the catalog , chapter, section, subsection, figure, graphic, parts list, and part number levels), effectivity information can be captured. For example, different part numbers may require different model numbers; different figures provide for different car numbers. Usually, the effectivity information can be captured directly at the appropriate point. However, in some cases, the effectivity information (series of model numbers, serial number ranges, etc.) is grouped and categorized (ex. “Effectivity A”) at the front of the manual, and referred to throughout the manual as a single letter. The RIF-EPC DTD allows for the creation of these effectivity groups.For example, suppose information concerning equipment model numbers is provided at the beginning of the manual. One group of effectivity is identified as “A” and covers Model numbers 8-645E, 8-645E3B, 8-645E3C, and 8-645F3B. Another group of effectivity is identified as “B” and covers model numbers 12-645E, and 12-645E3B, and 12-645E3C.The SGML markup for this information would be:

          <EFFECT-DATA> <EFFECT-CODE ID=”A”>A</EFFECT-CODE> <MODEL-NBR>8-645E</MODEL-NBR> <MODEL-NBR>8-645E3B</MODEL-NBR> <MODEL-NBR>8-645E3C</MODEL-NBR> <MODEL-NBR>8-645F3B</MODEL-NBR></EFFECT-DATA> <EFFECT-DATA> <EFFECT-CODE ID=”B”>B</EFFECT-CODE> <MODEL-NBR>12-645E</MODEL-NBR> <MODEL-NBR>12-645E3B</MODEL-NBR> <MODEL-NBR>12-645E3C</MODEL-NBR> <MODEL-NBR>12-645F3B</MODEL-NBR></EFFECT-DATA>

          A figure found in the body of the catalog is identified as being for model numbers defined in Effectivity Group “A”. At this point, the DTD allows for either the Effectivity Code (“A”) or the individual model numbers to be identified. To utilize the Effectivity Groups defined above, the markup would be the following:

          <FIGURE DRAW-NBR=”f100″ ID=”f01″> <EFFECT> <EFFECT-REF EFFECT-CODE=”A”></EFFECT> <TITLE>ENGINE EQUIPPED AND CRANKCASE AND OIL PAN ASSEMBLY</TITLE> …. </FIGURE>

          It should be noted the mapping of the effectivity codes is accomplished through the use of the SGML Attributes for the elements “effect-code” and “effect-ref”.

        5. List of Vendor’s Code, Name, Address, Phone Number The Catalog front matter may provide an overall list of vendors, organized by Name, Address, and Phone Number, and referenced by a Vendor Code. Vendor Part Numbers included in parts lists must identify the vendor code through the use of the attribute “vendor-code” of the element “vendor-part-nbr”. The DTD provides for explicit tagging of this information, in an effort to provide functional capabilities to the Electronic Parts Catalog. (see “vendor-list”)
        6. List of Abbreviations The Catalog front matter may provide a list of abbreviations, explicitly tagged as groups of terms and definitions. (see “abbrev-list”)
        7. List of Definitions The catalog front matter may provide a list of definitions, explicitly tagged as groups of terms and definitions. (see “def-list”)
      2. Body Text The Task Team made a concerted effort to limit the ability to incorporate maintenance and operational information within their Electronic Parts Catalogs. To be in concert with best Industry practices, the RIF envisions separate DTDs developed for Functional Maintenance Manuals. However, the RIF-EPC DTD does allow for limited narrative text in the body of an EPC, provided such text can be ‘linked’ or associated with a specific figure, parts list, or part number. The RIF-EPC DTD defines two elements to embody this narrative text: “Associated Text” (see “assoc-text“) and “Supporting Table” (see “support-table“).
        1. Associated Text Associated text is considered as supplemental textual information associated with a figure, parts list, and/or an individual part number. The SGML Element “assoc-text” is therefore an optional element within the content model for a Figure (“figure”), a Parts List (“parts-list”), and individual items of a Parts List (“item-group”, “subitem-group”).Associated text can consist of:
          • General Notes (see “general“), which can contain a title and an numbered/unnumbered subordinated list.
          • Safety Notes (see “safety“), which can contain a title and an numbered/unnumbered subordinated list.
          • Warnings (see “warning“), which can include paragraph text and/or graphics.
          • Cautions (see “caution“), which can include paragraph text and/or graphics.
          • Notes (see “note“), which can include paragraph text and/or graphics.
          • Tables (see “table“)
          • Graphics (see “graphic“)
        2. Supporting Table The purpose of the RIF-EPC DTD is to model parts catalog information, specifically for electronic “point-and-click” navigation. The DTD, provided in Appendix A, appropriately models Electronic Parts Catalog Illustrations and Parts Lists to enable simple point and click navigation to achieve unambiguous part number identification. However, during the process of document analysis, it was found that interpretation of supplemental physical part characteristic information was sometimes necessary for proper part selection. This supplemental physical part characteristic information is to be captured in the SGML element for supporting tables (see “supporting-table”).It should be noted that tabular information indicating physical part characteristics necessary for part selection could be encoded using the SGML element for Associated Text (see Section 2.3.2.1). However, since such physical part characteristic information is critical, during the part selection process, an effective EPC processing system should handle a “Supporting Table” differently from a general table provided as “Associated Text”. The Supporting Table is an optional element within the content model for a Parts List (“parts-list”), and individual items of a Parts List (“item-group”, “subitem-group”).Individual part numbers can be explicitly linked to a supporting table using the attribute value “supp-table”, the value of which would be the ID value of the “support-table” element. In addition, individual part numbers can be explicitly linked to an individual entry within the supporting table using the attribute value “supp-tbl-ent”, the value of which would be the ID value of a specific row in the supporting table. Once within a Supporting Table, the attribute value “item-ref” (the value of which would be the ID value of the “item-group” or “subitem-group” elements) provides an explicit link back to the Parts List Item. In addition, attribute value “parts-list-ref” (the value of which would be the ID value of the “parts-list”) provides an explicit link back to the Parts List as a whole.See Appendix C for Supporting Table examples.
    4. Data
      1. Part Information The purpose of the RIF-EPC DTD is to provide part information during the course of rail equipment maintenance and for input to Railroad accounting applications. A basic EPC utilizes the traditional detailed parts lists (“parts-list”) to capture the information necessary for part selection. Part information which can be encoded using the DTD includes:
        • Link to figure where part is illustrated (attribute “fig-ref” for element “parts list”; also see Section 2.6)
        • Internal cross reference link to other portion of document (see “ref” within “nomen-col”)
        • External cross reference link to other document (see “ref” within “nomen-col”)
        • Effectivity information (see Section 2.4.3 below) (see “effect” within “item-group”, “subitem-group“)
        • Relationship of part with it’s assembly or subassembly (see “part-nbr” attributes “higher-assem” and “assem-lvl”)
        • Relationship of part with it’s attaching parts (see “attach-parts“)
        • Part description, capturing the noun (ex “Bolt”), additional description (see “nomen-col“)
        • Quantity (see “qty“)
        • Unit of Measure (see attribute “um” for element “qty”)
        • Vendor Part Number and Vendor Code (“vendor-part-nbr”and attribute “vendor-code”)
        • Purchaser Item or Customer Item Number (“pur-item-nbr”)
        • Vendor Drawing Number (attribute “vendor-draw-nbr”)
        • Vendor Revision Drawing Number (attribute “vendor-rev-draw-nbr”)
        • Revision number, revision date (attributes “rev” and “revdate”)
        • Supporting physical part characteristics (see “support-table“)
      2. Drawing Data Information about individual illustrations can be captured using various elements and attributes defined in the RIF-EPC DTD. The element “epc-fig” groups a figure with it’s parts list in the DTD. These groups of figures and parts list may be collected in sections or subsections of a chapter. A figure is actually a collection of a figure title and at least one graphic image. The seller code associated with the figure can be identified with the attribute “seller-code” on the Figure. Drawing numbers for individual graphic images can be captured with the “graphic” element’s “draw-nbr” attribute. The image is identified using the “graphic” element’s “filename” attribute.If the graphic is to be handled as a “foldout”, the attribute value “foldout” for the “graphic” element should indicate “yes”. This is a paper paradigm that has no relevance to an EPC, however, it will have importance to a publishing system.Revision number and revision date can be captured for the figure as well as the graphic image using the “rev” and “revdate” attributes. Effectivity information can be captured for the figure and graphic image using the “effect” element.
      3. Effectivity Effectivity is used to associate a given set of information (illustration, part number, etc.) to a distinct category of products, and is essential for proper part selection. The RIF-EPC DTD allows effectivity information to be captured at the following hierarchical levels of an Electronic Parts Catalog: The Catalog, Chapter, Section, Subsection, Figure, Graphic Image, Parts list, and Part Number Levels. The effectivity information that can be captured at these levels includes:

        In an effort to provide functional capabilities to the Electronic Parts Catalog, the low and high numbers of the serial, road, lot and component location ranges are captured in attribute values “low” and “high”.

        Alternatively, an effectivity reference code (“effect-ref”) can reference effectivity information that was defined in the Effectivity Cross Reference (“effect-xref”) element (see Section 2.3.1.4 above).

      4. Physical Part Characteristics As discussed in Section 2.3.2.2, association of part-specific data is sometimes necessary for proper part selection. In such cases a specific part cannot be selected based on a “point-and-click” from an illustration. Rather, multiple part numbers are thus identified and additional information reviewed to select the desired part. This additional information is to be encoded as a “supporting table” and can be linked from the individual part numbers or from the entire parts list.
    5. Revision Control The RIF-EPC DTD provides for the tracking of revision numbers (“rev”) and revision dates (“revdate”) on all hierarchical elements in the DTD. The requirement for the identification of this revision history will have to be defined under each specific rail vendor/ rail company contract.
    6. Links The EPCES must support full ‘point and click’ navigation enabling the ability to drill down to the smallest component level.
      1. HyTime Links The RIF has concluded to limit the use of HyTime linking as follows:
        • A figure “callout” to another figure (for visual references)
        • A figure “callout” to an item-group (part number, effectivity, nomenclature, etc.).

        HyTime provides a representation of interconnections between and within components of information. The RIF-EPC DTD incorporates HyTime to provide interconnection between a point on a graphic (commonly a numerical “callout”) to textual information or another graphic.

        To uniformly describe a graphic, EPCES overlays the actual graphic with a virtual 2048 x 2048 (2K x 2K) grid. Because EPCES uses a virtual grid, it is necessary to map the actual pixel value of the graphic to the virtual grid. This approach (mapping the actual graphic to the EPCES grid) enables the hot spot to be display device (hardware) independent.

        The graphic and hot spot may be thought of as a rectangle. A rectangle can be described by using two points: (left, top) and (right, bottom). The EPCES algorithm assumes that the graphic and hot spot are normalized rectangles (i.e., the left is a lesser value than the right and the top is a lesser value than the bottom).

        1. Grid and Graphic Definitions
          VGh = 2048 Virtual Grid Horizontal Size
          VGv = 2048 Virtual Grid Vertical Size
          Wg = Width of Graphic (Horizontal)
          Hg = Height of Graphic (Vertical)
          GSFh = VGh / Wg Horizontal Grid Scale Factor
          GSFv = VGv / Hg Vertical Grid Scale Factor
        2. Graphic Hot Spot The hot spot is defined by an upper left coordinate (ULx, ULy) and a lower right coordinate (LRx, LRy).ULx = Upper Left Horizontal Position of Hot Spot (left of rectangle) (graphic) ULy = Upper left Vertical Position of Hot Spot (top of rectangle) (graphic) LRx = Lower Right Horizontal Position of Hot Spot (right of rectangle) (graphic) LRy = Lower Right Vertical Position of Hot Spot (bottom of rectangle) (graphic)
        3. Translation of Graphic Hot Spot to EPCES Grid
          RX = ULx X GSFh Upper Left Horizontal Position (left of rectangle) (Grid)
          RY = ULy X GSFv Upper Left Vertical Position (top of rectangle) (Grid)
          RW = (LRx X GSFh) – RX Width of rectangle (Grid)
          RH = (LRy X GSFv) – RY Height of rectangle (Grid)
        4. Example The following is an example of the mapping algorithm utilized by HyTime in placing hot spots. This example illustrates how to map the actual graphic to the EPCES grid (determine and implement the RX, RY, RW and RH) values. In this example the desired graphic hot spot upper left coordinate (UL) is (220,360), the lower right coordinate (LR) is (240,380) and the width and height of the graphic is (256,512).
          • First, establish relative grid scale factor:

            Divide VGh by Wg(2048 / 256) = 8 (GSFh) Divide VGv by Hg(2048 / 512) = 4 (GSFv)

          • Determine upper left-corner grid hot spot coordinates:

            Multiply ULx by GSFh (220 X 8) = 1760 (RX) Multiply ULy by GSFv (360 X 4) = 1440 (RY)

          • Determine lower right-corner grid hot spot coordinates:

            Multiply LRx by GSFh (240 X 8) = 1920  Multiply LRy by GSFv (380 X 4) = 1520 

          • Obtain the grid hot spot Width (RW) and Height (RH) values:

            Subtract RX from (LRx X GSF)1920 – 1760 = 160 (RW) Subtract RY from (LRy X GSF)1520 – 1440 = 80 (RH)

          a-30t

          Figure 1

          The following is the HyTime encoding which implements the above sample hot spot:

          <GRAPHIC FILENAME=figure1>

          <HOT SPOT ID=ID1.SPOT IDREF=”ID1.TEXT” GRAPHIC=figure1 RX=”1760″ RY=”1440″ RW=”160″ RH=”80″>

          <!(if there were multiple hot spots they would continue to be described as follows:)>

          <HOT SPOT ID=ID2.SPOT IDREF=”ID2.TEXT” GRAPHIC=figure1 RX=… <HOT SPOT ID=ID3.SPOT IDREF=”ID3.TEXT” GRAPHIC=figure1 RX=… <HOT SPOT ID=ID4.SPOT IDREF=”ID4.TEXT” GRAPHIC=figure1 RX=…

          </GRAPHIC>

      2. DTD Navigational “Links” With the exception of linking to/from a figure ‘hot spot’, the functional “point-and-click” capabilities of an Electronic Parts Catalog will be accomplished by normal interpretation of the data constructs defined in the DTD. The content models for the hierarchical elements within an Electronic Parts Catalog Chapter allow for navigation and ‘linking’ to subordinate elements. For example:
        • The content model for “chapter” allows for navigation of its sections.
        • The content model for “epc-fig” allows for linking of a figure with its parts list.
        • The content model for “figure” allows for linking of graphics with associated text.
        • The content model for “parts-list” allows for linking of part numbers with its supporting table and associated text.
      3. SGML ID/IDREF “Links” In addition, the DTD allows for explicit linking between some of the above elements by use of ID/IDREF attribute values. By using ID/IDREFs, it is not always necessary to interpret the DTD model to access desired information. In addition, sometimes cross referencing relationships cannot be achieved by DTD Navigation. The DTD uses ID/IDREF links in the following cases:
        • A Part Number (“part-nbr”) can be linked to a figure via use of the “fig-ref” attribute.
        • A Part Number (“part-nbr”) can be linked to physical part characteristics identified in a Supporting Table (see Section 2.3.2.2) by use of the “supp-table” attribute.
        • The part number can also be linked to a specific row in the supporting table by use of the “supp-tbl-ent” attribute.
        • A Part Number can be linked to the part number for it’s higher assembly by use of the “higher-assem” attribute.

        As described in Section 2.3.1.4, effectivity information defined in the “effect-xref” (Effectivity Cross Reference) Section can be referenced in the body of the EPC by use attribute “effect-code” of the element “effect-ref”. As described in Section 2.3.1.5, vendors listed in the “vendor-list” can be referenced from a vendor part number (“vendor-part-nbr”) by use of the “vendor-code” attribute.

        Cross references to other portions of the catalog are achieved by use of the “Internal Cross Reference” (“refint”) element. The attribute value “refid” for the element “refint” provides a link to any element within the tagged file with the attribute “id” with the same value. The attribute “reftype” for element “refint” provides information on the purpose of the cross reference. The possible types of reference include:

        • ADR – Additional Detail Reference. A lateral reference to other figures in the EPC displaying additional related details.
        • DBR – Detail Breakdown Reference. A reference to a figure in the EPC containing a breakdown of the part number in the part number field.
        • ILR – Illustration Reference. A reference to another figure in the EPC which displays related coverage.
  3. Media Exchange – MIL-STD-1840BThe EPCES utilizes the Military Standard for Automated Interchange of Technical Information (MIL-STD-1840B) to specify file formats, naming conventions and media types for an exchange of EPC information.ATA’s MEDSPV61 was also considered. However, the ATA specification does not include file naming conventions or file formats, leaving them to be determined by exchanging parties. MIL-STD-1840B, on the other hand, includes these specifications and provides RIF the specifications for unambiguous exchange of EPC information.MIL-STD-1840B, however, does not specify the wide variety of media that RIF is certain to utilize. MIL-STD-1840C, now in final draft mode, addresses a wide variety of media including random access and optical disk, cartridge tape and electronic transmission, overcoming this shortcoming of 1840B. Therefore EPCES specifies 1840B with additional media specifications contained in 1840C (draft). RIF will want to review and adopt the MIL-STD-1840C specification upon publication.The requirements for packaging an EPCES exchange follow.
    1. Media Options MIL-STD-1840B specifies 9-track tape, however, allowances are made for alternative media (see 1840B, Section 5.4.2) to be negotiated by the sender and receiver. The EPCES specifies 1840B media and alternative media as listed in 1840C (draft) as follows:EPCES Media support as specified in 1840B:
      • 9 Track Magnetic Tape
      • 1840C (draft) supports virtually all media including:
      • Cartridge Magnetic Tape (see 1840C Appendix A Section 4.2)
      • Random Access Media (see 1840C Appendix A Section 5)
        • Floppy disks
        • Removable disk drives and disk cartridges
      • CD-ROM (see 1840C Appendix A Section 5.3)
      • Electronic transfers (see 1840C, Appendix A Section 6)

      File packaging, content and naming as specified in 1840B shall be applied to all media.

    2. EPCES Packaging MIL-STD-1840B defines a three tier structure under which files are grouped. The top tier, comprising a complete exchange, is defined as a “Transfer Package”. Each Transfer Package may have one or more second tier “Transfer Sets” (except sequential media where a transfer package is composed of only one transfer set). A Transfer Set is a collection of “Transfer Units” (third tier). A Transfer Unit is defined as, “[a] collection of files consisting of one transfer unit declaration file and one or more data files (the smallest collection of files to make a successful interchange of technical information).” See 1840B, Section 3.5.Producers of EPCES catalogs, to support the logical grouping of files, will determine the number of Sets and Units in an exchange (Transfer Package). It is expected that a typical EPCES Transfer Package will consist of one Transfer Set containing one or a small number of Transfer Units.
    3. SGML Document Transfer Unit MIL-STD-1840B, in order to support a wide variety of technical documentation, provides for five types of Transfer Units, only one of which is applicable to EPCES – the SGML Document Transfer Unit.An SGML Transfer Unit shall consist of the following elements:
      1. Transfer Unit Declaration File There shall be one Transfer Unit Declaration File to provide all information necessary to describe the transfer unit contents to the receiver. It uniquely identifies the contents and counts each file type contained in the transfer unit (see 1840B, Section 5.3.1.2).Figure 2 is an example of the content of the EPCES Transfer Unit Declaration File. This example is of the Transfer Unit Declaration for the Phase III deliverables (see Section 3.4 for listing of files specified in this Transfer Unit Declaration).
        version: MIL-STD-1840B, 0, 19921103
        srcsys: AIT 979 Spaulding Ave., Grand Rapids, MI 49546
        srcdocid: EPCES Phase III documentation ver 0.92
        srcrelid: EPCES Phase III document ver 0.9
        chglvl: ORIGINAL, 0, .01, 19960220/0900:00
        dteisu:19960220/0900:00
        dstsys: RIF, c/o Mr. Dennis Smid, Union Pacific Railroad, 1416 Dodge St., Omaha, NE
        dstdocid: Phase III Doc 0.92
        dstrelid: Phase III Doc 0.91
        dtetrn: 19960220/1200:00
        dlvacc: RIF/AIT Amended Contract 19951009
        filcnt: A6, G1, T2, C1, X2
        ttcls: UNCLASSIFIED
        doccls: UNCLASSIFIED
        doctyp: Final EPCES specification
        docttl: EPCES Phase III Document
        transacttyp: SGML

        Figure 2

      2. Document Type Declaration File This optional file shall contain the EPCES identifier for the SGML document being transmitted. If this file is absent, then the document type declaration of the SGML document shall be the first data in the text source file. (see 1840B, Section 4.4.4 and this Document, Appendix A.1)
      3. Transfer Unit Data Files EPCES allows for all data files specified in 1840B with the exception of the Formatting Output Specification Instance (FOSI) data file. FOSI provides for the reproduction of hard copy output which is not specified in EPCES (see 1840B Section 4.2.3.f). The following Data Files are supported:
        1. SGML Coded Text Source File(s) These are SGML coded ASCII text files, marked up in accordance with EPCES. If a document type declaration file is present in the SGML document transfer unit, then the text source file shall make up the document element of the SGML transfer unit. If there is no document type declaration file, then the text source file shall make up the document type declaration set or EPCES identifier followed by the document element. (see 1840B, Section 4.4.5)
        2. Illustration file(s) in CGM or TIFF format “Each set of text source files for an exchange shall be supported with an illustration data file for each graphic entity in the technical publication except where there are multiple instances of the same graphic entity in different locations in the technical publication. In this situation, a single illustration data file may be used to satisfy all of the graphic entity instances” (see 1840B, Section 4.4.7).The EPCES TIFF specification does not conform to the CALS raster format. An error will occur within 1840B software when packaging or unpackaging an exchange if EPCES TIFF files are packaged with the TIFF “R” designation. Therefore EPCES specifies an exception to the 1840B naming conventions for TIFF files. EPCES will designate TIFF files with the 1840B “A” designation indicating a “contract defined” file specification (see Section 3.3.3.3 below and 1840B 5.3.2.1).
        3. Supported Optional Files
          • SGML Text Entity File(s) (see 1840B, Section 4.2.3.d)
          • Special text files per contract, (see 1840B, Section 4.2.3.g)
          • Contract defined data files (see 1840B, Section 4.2.3.f)
      4. File Naming MIL-STD-1840B requires all files be renamed when packaged according to naming conventions defined by file type and transfer unit number within a transfer package. Files would be returned to their original name when unpackaged by the recipient (see 1840B, Section 5).
      5. Header Records MIL-STD-1840B specifies each Transfer Unit data file shall have a header record. 1840B compliant software will automatically bundle and unbundle data files with the appropriate header information. Header files contain information used to retain information such as original file names, document identification and document revision information (see 1840B 5.3.2.2).Figure 3 graphically depicts an EPCES compliant exchange (Transfer Package) for this contract’s Phase III deliverables.a-31t

        Figure 3

      6. Media Labeling MIL-STD-1840B specifies all media shall have a media label affixed to it. (see 1840B, Section 5.5.1). An EPCES label shall be as follows:
        • Company Name
        • Date (of transfer)
        • Version (MIL-STD-1840B, 0)
        • Provider Code
        • Volume ID (4 letter identifier chosen by publisher plus a two digit volume number)
        • Density/Capacity
        • Media number
        • Point of Contact