last updated 2000:03:14:1400EST by rws
NOTE 1: the DTD presented here has evolved to a new form that has not been published yet.
NOTE 2: GoeCities keeps correcting my lt; characters to < which makes the XML tags "invisible" you may have to view the page source to see the DTD.

A Simple XML Subset of PLIB

Table of Contents

Disclaimer

DO NOT ASSUME THAT THIS IS ALL THERE IS TO PLIB! THIS IS A 'SIMPLE' SUBSET THAT IS BELIEVED TO CAPTURE 60%-80% OF THE U.S. SHIPBUILDING COMMUNITY'S IMMEDIATE NEED FOR DATA EXCHANGE.

Introduction

The purpose of this 'paper' is to distill the key ideas from ISO 13584 (Parts Libraries or PLIB) that are of use to the U.S. Shipbuilding industry and to present these ideas in an 'easy to absorb' manner.  Parts library technology is becoming more relevant as we move forward towards electronic commerce and digital inventory management systems. What is new is that ISO 13584 offers a vender neutral data standard for describing and exchanging part library data. ISO 13584-24 Industrial automation systems and integration: Parts Library: Logical Resource: Logical model of supplier library is the heart of the PLIB standard and will be going out for a DIS (draft international standard) ballot in the winter of 1999. It is reasonable to expect that this document will be an international standard by the end of the year 2000.

The majority of the important ideas presented in this paper are distilled from ISO 13584-42 Industrial automation systems and integration: Parts Library: Description methodology: Methodology for structuring part families. ISO 13584-42 became an international standard in 1998. ISO 13584-24 expands on the data model presented in ISO 13584-42 by adding several useful extensions for describing and exchanging part library data. The nature of these extensions and the relationship between these two documents will be discussed later in this paper.

Data Formats for this 'Paper'

PLIB uses the EXPRESS language defined in ISO 10303-11 for describing its data models. While this is suitable (and maybe even useful) for hard-core computer scientists, EXPRESS is difficult for many people to grasp (including the author). Furthermore, there are some copyright issues with sharing portions of ISO documents that can be avoided by not speaking in EXPRESS here. Those readers who are interested in learning more about PLIB should get copies of the standard from ISO or their representative national body. US PRO is the ANSI accredited standards development organization responsible for this body of work in the U.S. Contact them (uspro@aticorp.org) for additional information or to obtain copies of the documents. The PLIB page at NSWC-Carderock Division is also a good place to start for more information about the PLIB standard.

EXPRESS organizes data models into schemas. Schemas define data types, entities, attributes of entities, relationships between entities, and rules that data stored in attributes of entities must meet. ISO 13584-42 defines the ISO13584_IEC61360_Dictionary_Schema that contains most of the entities of interest to this paper. Of the many schemas defined in ISO 13584-24, only the ISO13584_g_m_iim_schema is of interest to this paper.

In this paper XML will be used to capture the key ideas from PLIB. EXPRESS entities and attributes will be expressed as XML document elements. This greatly simplifies the complexity of the PLIB schemas. Unfortunately, this also hides many interesting features of the PLIB schemas, but this is O.K. for an introduction like this.

I make the bold claim that 60% of the U.S. shipbuilding community's part library data exchange requirements can be met with the following simple XML DTD: 



<!DOCTYPE SUPPLIER_LIBRARY [

<!ELEMENT SUPPLIER_LIBRARY (CLASS*)>

<!ATTLIST SUPPLIER_LIBRARY BSU CDATA #REQUIRED>

<!ELEMENT CLASS (CNAME, PROPERTY*, TABLE*, CLASS*)>

<!ATTLIST CLASS BSU CDATA #REQUIRED>

<!ELEMENT CNAME (#PCDATA)>

<!ELEMENT PROPERTY (PNAME, PTYPE)>

<!ATTLIST PROPERTY BSU CDATA #REQUIRED>

<!ELEMENT PNAME (#PCDATA)>

<!ELEMENT PTYPE (#PCDATA)>

<!ELEMENT TABLE (COLUMN*)>

<!ATTLIST TABLE BSU CDATA #REQUIRED>

<!ELEMENT COLUMN (TD*)>

<!ELEMENT TD (#PCDATA)>

]>

I make a further claim that another 20% of the U.S. shipbuilding industry's part library data exchange need can be made by making a similar simplification of the ISO13584_f_m_iim_schema from ISO 13584-24, but that effort is not completed.

The rest of this paper will explain the DTD listed above and will describe how this DTD reflects PLIB compliant data. If you have access to Internet Explorer version 5.0 or higher, you can view the XML files directly. If you are loyal to Netscape (as your author tries to be) you will have to be satisfied with the screen shots provided. In either case it is important to remember that XML is only the data format and that it is the applications capable of supporting this format that are of interest.

Basic Semantic Unit

PLIB uses the idea of a Basic Semantic Unit (BSU) to create globally unique identifiers for all the definitions and data exchanged by its schemas. A BSU is simply a text string. PLIB uses a very clever mechanism of ensuring that BSUs are unique. Each BSU is required to point to the organization that defined it and by using an international registration mechanism defined in ISO/IEC 6523-1:1998, Information technology - Structure for the identification of organizations and organization parts - Part 1: Identification of organization identification schemes, PLIB ensures that each organization is uniquely identified.

Currently your company's Dun & Bradstreet number (DUNS) is the best way for identifying your U.S. company under this scheme. The ICD code for Dun & Bradstreet's numbering system is 0060. As an example, my company is NSWC Carderock Division and our DUNS number is 05-066-9001. This means that if I use 0060/050669001 as the Supplier_BSU, I have uniquely identified my company as the data supplier. For more information about using DUNS numbers for Supplier_BSUs, please click here.

There are four BSUs of interest to this paper:

  1. Supplier_BSU identifies the data supplier for a library
  2. Class_BSU identifies a class defined by a data supplier
  3. Property_BSU identifies a property of a class defined by a data supplier
  4. Table_BSU identifies a table containing instance data for properties of a class defined by a data supplier
The first three BSUs are defined in ISO13584_IEC61360_dictionary_schema defined in ISO 13584-42. The Table_BSU comes from ISO 13584-24. PLIB requires that a Class_BSU must point to a Supplier_BSU, that a Property_BSU must point to a Class_BSU, and that a Table_BSU must also point to a Class_BSU. The following XML is intended to illustrate this relationship:

<SUPPLIER_LIBRARY BSU="0060/050669001">
<CLASS BSU="264___psbvloff">
<PROPERTY BSU="nominal_pipe_d">
<TABLE BSU="T1">
</CLASS>
</SUPPLIER_LIBRARY>

Supplier Library

The importance of the Supplier_BSU is reflected in the fact that it is an attribute of the DOCTYPE in the above DTD. The two lines that define the XML SUPPLIER_LIBRARY element are shown again here:

<!ELEMENT SUPPLIER_LIBRARY (CLASS*)>
<!ATTLIST SUPPLIER_LIBRARY BSU CDATA #REQUIRED>

This says that:

  1. A SUPPLIER_LIBRARY may contain zero or more CLASS elements
  2. A SUPPLIER_LIBRARY must have a BSU.
Additional restrictions not captured in the XML are:
  1. PLIB requires that the Supplier_BSU be no more than 18 characters long.

Class

Classes are the workhorse of the PLIB standard. Classes are organized into hierarchies that organize properties and tables. The requirement that every Class_BSU must point to its Supplier_BSU is addressed by making CLASS subordinate to SUPPLIER_LIBRARY. The three lines that define the XML CLASS element are shown again here:
<!ELEMENT CLASS (CNAME, PROPERTY*, TABLE*, CLASS*)>
<!ATTLIST CLASS BSU CDATA #REQUIRED>
<!ELEMENT CNAME (#PCDATA)>

This says that:

  1. A CLASS must have a CNAME (class name) followed by
  2. Zero or more PROPERTYs and
  3. Zero or more TABLEs and
  4. Zero or more CLASS; yes this recursion allows a sub-class/super-class hierarchy to be defined.
  5. A CLASS must have a BSU.
  6. A CNAME is just a string.
Additional restrictions not captured in the XML are:
  1. PLIB requires that Class_BSUs be no more than 14 characters long.
  2. The order of PROPERTY elements must match the order of TABLE COLUMNS (see below).

First example

The class level description of a parts library is useful for showing how the library is organized. This is the approach that was accepted by the Marine Machinery Association in its library development work in the winter of 1997. An example of this sort of library description is shown in the following figure.


click here to see the XML file. click here to see the p21 file.

Property

Properties define the type of data to be exchanged. Properties belong to classes, and the requirement that every Property_BSU must point to its Class_BSU is addressed by making PROPERTY subordinate to CLASS. The four lines that define the XML PROPERTY element are shown again here:

<!ELEMENT PROPERTY (PNAME, PTYPE)>
<!ATTLIST PROPERTY BSU CDATA #REQUIRED>
<!ELEMENT PNAME (#PCDATA)>
<!ELEMENT PTYPE (#PCDATA)>

This says that:

  1. A PROPERTY must have a PNAME followed by
  2. A PTYPE.
  3. A PROPERTY must have a BSU.
  4. A PNAME is just a string.
  5. A PTYPE is just a string.
Additional restrictions not captured in the XML are:
  1. PLIB requires that Property_BSUs be no more than 14 characters long.
  2. The order of PROPERTY elements must match the order of TABLE COLUMNS (see below).
  3. PTYPE should be one of the basic data types: REAL, INTEGER, or STRING.

Second example

Many organizations have found it useful to describe a classification hierarchy along with the allowed data types for each class' property. The IEC made this decision, which is why the ISO13584_IEC61360_dictionary_schema stops at this level of description. The following figure shows how properties are related to classes in the current XML DTD. NOTE that it is not possible to say that f1=5. It is only possible to say that f1 is of type REAL.


click here to see the XML file. click here to see the p21 file.

Table

Tables are where the wheels meet the pavement, and are one of the extensions added to PLIB by ISO 13584-24. Tables store the actual data values to be exchanged. Tables store data in columns rather than rows, which can be confusing for some folks. Tables belong to classes, and the requirement that every Table_BSU must point to its Class_BSU is addressed by making TABLE subordinate to CLASS. The four lines that define the XML TABLE element are shown again here:

<!ELEMENT TABLE (COLUMN*)>
<!ATTLIST TABLE BSU CDATA #REQUIRED>
<!ELEMENT COLUMN (TD*)>
<!ELEMENT TD (#PCDATA)>

This says that:

  1. A TABLE may have zero or more columns.
  2. A TABLE must have a BSU.
  3. A COLUMN may have zero or more TD.
  4. A TD is just a string.
Additional restrictions not captured in the XML are:
  1. PLIB requires that Table_BSUs be no more than 14 characters long.
  2. The order of COLUMN elements must match the order of PROPERTY elements listed for the class.
  3. Each column of the table must have the same number of entries.

Third example

Associating data with the properties of classes is how electronic descriptions of parts are exchanged. The following figure (and associated XML file) shows the first 10 rows of the part data for a lever operated, flange faced, ball valve. The hierarchy information was taken from the fifth data dictionary defined for the MMA on April 17, 1998. To see a picture of the ball valve, go to psbvloff.html.


click here to see the XML file. click here to see the p21 file.
 
 

Translation Tool

To assist in the study of the PLIB standard (ISO 13584), a translator has been written which translates a file conforming to the XML dtd listed above into a file conforming to the ISO13584_g_m_iim_schema defined in ISO 13584-24. The translator has been written using lex and yacc along with some simple ANSI C routines. The translator has successfully been compiled and tested under LINUX and Microsoft Windows NT 4.0.

Acquiring the Tool

The translator is available in source form which includes the input and output for lex, the input and output for yacc, the support C routines, and a makefile. The makefile builds the executable from the output from lex and yacc along with the support C. To obtain the source, click here.

For windows users who don't have a compiler, a file which contains the executable, along with a simple batch file for running the executable is available. To obtain this executable, click here.
 

Running the Tool

From a LINUX prompt, type the command cat | xmlgiim >   where is the name of a file conforming to the DTD at the beginning of this paper and is the name of the file you wish to generate.

From a DOS prompt, type the command type | xmlgiim.exe >   where is the name of a file conforming to the DTD at the beginning of this paper and is the name of the file you wish to generate. Or you may use the batch file by typing the following command xml2giim where is the name of a file conforming to the DTD at the beginning of this paper and is the name of the file you wish to generate. If you open the batch file "xmlgiim.bat" in a text editor, you will see that it simply translates the second command into the first.
 

Building a Library

Due to the limitations of the XML DTD listed at the beginning of this paper, there are certain rules that must be followed when building libraries. The most significant rule is that properties and tables should only be added to 'leaf nodes' in the parts hierarchy. 'Leaf nodes' are classes which do not have any subclasses.  The reason for this restriction is that the DTD does not reflect PLIB's inheritance mechanism. Specifically, when a table is defined inside a class, it only looks for properties that are also defined in the class. The table does not look at super classes to find definitions for its columns. On a practical level, this makes reading the XML files in a text editor a little easier since the table and property definitions are collocated within a single class.

Syntactically, there is no problem with adding properties and tables to super classes within a parts hierarchy. In fact the DTD does allow it. Unfortunately, the current translator does not enable subclasses to inherit these property definitions or table entries. If this sort of inheritance is really important to you, you may define properties in super classes and repeat them in the subclasses, but be warned, many hard-core data modelers find this kind of data redundancy to be very very bad.

A second rule that is worth repeating here is that the columns of a table correspond to the properties in a class. The first table column corresponds to the first property defined in the class.  The ordering of properties and table columns is the responsibility of the editor of the XML file. The translator does very little to verify the alignment of columns and properties.