The PIF Process Interchange Format and Framework

Jintae Lee, Gregg Yost and the PIF Working Group[1]
Version 1.0
December 22, 1994

Table of Contents
1. Abstract
2. Introduction
3. History and current status
4. PIF
5. Alphabetic Class Reference
6. Extending PIF
7. Appendix A: PIF Syntax
8. Appendix B: An Example PIF File
9. References

6. Extending PIF

PIF provides a common language through which different process representations can be translated. Because there will always be representational needs local to individual groups, however, there must also be a way to allow local extensions to the description classes while supporting as much sharing as possible among local extensions. The Partially Shared Views (PSV) scheme has been developed for the purpose (Lee & Malone, 1990). PSV integrates different ways of translating between groups using different class hierarchies (e.g. pairwise mapping, translation via external common language, translation via internal common language) so as to exploit the benefits of each when most appropriate.

A group using PSV translates a PIF object X into their native format as follows:

1. If X's class (call it C) is known to the group and the group has developed a method that translates objects of class C into their native format, then apply that translation method;
2. Otherwise, translate X as if it were an object of the nearest parent class of C for which (1) applies.

This translation scheme allows groups to share information to some degree even if they do not support identical class hierarchies. For examples, suppose that Group A supports only the standard PIF ACTOR class, and that Group B in addition supports an EMPLOYEE subclass. When Group A receives a process description in Group B's variation on PIF, they can still translate any EMPLOYEE objects in the description as if they were ACTOR objects.

What happens to any information that is in an EMPLOYEE object that is not in a generic ACTOR object? That will vary according to the sophistication of the translator and the expressive power of the target process representation. Ideally, the translator will preserve the additional information so that it can be viewed by users and reproduced if it is later translated back into PIF.

For example, suppose EMPLOYEE has a "Medical-plan" attribute, which is not part of PIF ACTOR objects in general. Then, ideally, Group A's translator would

Translate any Medical-plan attributes into a form that the user could view in the target system (even if it only as a textual comment)[2] and
When the information is re-translated into PIF in the future (from Group A's native format), it is emitted as an EMPLOYEE object with the same value for the Medical-plan attribute (and not simply as an ACTOR object with no Medical-plan attribute). MIT researchers are currently investigating this general problem of preserving as much information as possible through "round trips" from one representation to another and back.

Translators that can follow these conventions will minimize information loss when processes are translated back and forth between different tools. The details of PSV can be found in (Lee & Malone, 1990).

In the current version of PIF, each PIF file begins with a declaration of the class hierarchy for the objects described in the file. PSV uses this class hierarchy to translate objects of types that are unknown to a translator. To eliminate the need for PIF translators to do any other inheritance operations, however, all PIF objects should contain all of their attributes and values. For instance, even if the value of a given attribute is inherited without change from a parent, the attribute and value are repeated in the child.