Jintae Lee, Gregg Yost and the PIF Working Group
December 22, 1994
A group using PSV translates a PIF object X into their native format as follows:
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
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.