Problem Statement
Reviewers were asked to describe any clarifications and/or alternative views to the Problem Statement described in the RFC.

1. Agree with problem statement.
2. The statement is generally OK. My main concern is the description of the way Joe Geophysicist is expected to "construct" an application from many applets. My experience suggests that this is likely to be too complex a notion to work in theory.

   Having seen such a system in operation in Paris on 24 June I am less skeptical. However, I am not sure how much smoke and mirrors was in use there! If I assume no smoke and mirrors then I can see that the problem statement could be rewritten in terms that a "normal" user, rather than a "super" user, can understand.

   I would suggest that that Joe chooses, from a toolbox, the appropriate tools for the job. The more complex the task, the more tools are selected to work the problem.

3. A big additional component of consistent interaction is in the definition of "selections" of more than one object, for example a list of wells, seismic lines, surveys, or leases.

   Someone may, for example, want to produce a 3-D display showing only 10 seismic lines, which are also to be shown on a map and used for a gridding and contouring job, but which are selected from many different surveys and with varying shotpoint sub-ranges.

   Such groupings of objects have to be managed in a consistent manner.

4. The problem statement is clear and the example based approach used makes it easy to understand. However, this problem is not unique to the oil exploration industry -- many other industries are also looking for similar levels of "Plug & Play" interoperability across heterogeneous platforms with support for multiple languages.
5. The problem statement, or, at least, the example to illustrate it, seems a bit restrictive or needs to be more delimited. The perimeter of the target is a bit vague. Should the application interaction target be a "microview" or a "macroview"? The current RFC is more "micro" level oriented. The macroview will have to address other concerns such as:
   • To define an application "on the fly" a user will assemble graphic components, data-like components or processing components. The interaction model will have to take into account all those kinds of components and not only the graphic ones. For instance, a processing component may generate an event (e.g., end of ...) to automatically activate a graphic representation pre-defined by the user or something else.
   • There is also a play/replay requirement. One goal of using an application suite is to facilitate or accelerate a process. Once a workflow has been specified, the user would like to replay it with a different set of information. The replay may require mixing interactive behaviors and "automatized" scenarios.
   • Interaction is not limited to one user. The trend is more and more toward multi-disciplinary activities. That means several users may interact, within some limits, to build collectively a common view of a model (e.g., an expert based in Pau can assist a geophysicist based in Nigeria). The concepts of "interaction sharing" have to be introduced to cover those kinds of requirements.
   • Interaction is knowledge driven. The rules and constraints can be implicit (e.g., the user is accustomed to performing one action before the other, etc.) or explicit. Rules may be defined at a "micro" level - apparently the current target of the RFC - or at a macro level (e.g., multi-user or multi-application workflow).
6. There is another view of the problem based on user expectations. In the example, Joe is using a variety of applets that could have been implemented by different vendors. These have been assembled into what appears to Joe to be a single application. For Joe to be productive in using this collection of applets, their interaction behavior must be predictable and repeatable, with a state that is intuitively understood. There cannot be race conditions, applet interlocks, and other symptoms of non-robustness. Given that the applets may be running asynchronously in their own address spaces, achieving robustness requires a coherent and consistent model of application interaction.
7. The interaction behavior standard goes well beyond the E&P UI Style Guide defining the general appearance and layout of a windowed E&P display, user interaction with windows and menus, user-control of graphical elements, and a behavioral model for drawing graphical elements. To say subsequently that "it drastically reduces application design risks, as a great part of the complexity of an application in terms of behavior would be "built in" overstates its value. VB creator Alan Cooper puts it this way: "Standards are easily the biggest aid to interface designers. But standards are also the biggest obstacle to interface designers... I hear amateur user interface designers and programmers speak of user interface standards all the time as though they are codicils recorded in a big book somewhere. It's as though Apple and Microsoft had figured out the right methods for all time and it is our duty to perpetuate them. Sure, both companies actually have published user interface guidelines, but both companies freely break them"--for example, when user performance with an application is demonstrated better another way (easier to learn, more efficient to use, measurably less errors, etc.). This lies at the heart of an iterative user-centered design and evaluation process methodology. So the proposed direction may take us into areas that eventually will be decided by the market anyway, or areas where we won't know how to define standards until our efforts are better informed by experience.

Solution Concepts
Reviewers were asked to describe any clarifications and/or alternative views to the Solutions Concepts described in the RFC.

1. Agree with solution concepts. It is essential to rapidly converge on the scope covered by application interaction.
2. Again, some of this may need to be put into user speak to help users understand what is being sought. This may help with the marketing.
3. The solution concepts presented seems to mix two things which I'd like to see clearly separated:
   • The "mouse clicks and menu options" used in typical workflows, which I don't think need an industry standardization as there is a general and consistent evolution of these things that is driven by software largely outside of the E&P sphere (including office systems, web applications and games)
   • The way in which interoperating applications can synchronize their activity so that they present a consistent and correct interface to the data and the available operations. This is an area that I think would benefit from standardization.
4. The concepts being dealt with in section 3 bear a remarkable similarity to those being considered in the OMG Business Objects group. Also, OMG is acutely aware of the importance of workflow and has a separate group for workflow.
5. The answer to the question asked above related to the Problem Statement may require extensions of the solution concepts. Currently the concept of "rules/constraint" is not explicit. There is an intent to deal with "consistency of ...?...." but the solution does not develop it. Currently activators are graphic oriented. The definition should be more generic because other components may generate events which can "activate and stop an interaction task. The proposed solution concept does not develop the integration in, or the link with, a distributed environment.
6. The concepts presented here are complex and, as presented, are linked to very fine grained behavior:
   • Does this model dictate the level of granularity of the applets?
   • Does this model support batch applications? How?
   • How would existing legacy applications participate in this model?
   • How do the concepts relate a Model-View-Controller paradigm based on an event mechanism?
   • Is the model consistent? Does it guarantee that interactions are predictable and repeatable?
   • Is the model complete? Are there any common use cases that would not be covered by the model? A state transition diagram might help to illustrate this.

General
Reviewers were asked to provide any additional comments regarding the RFC.

1. Interaction is meant to ease collaboration between applications. This requires first a good collaboration between the software vendors. This initiative has sense if and only if at least one of the main vendors gets actively involved.
2. The document appears to have been aimed at software writers and not at the user community. This may have been intentional or it may reflect the authors' knowledge base. It should be restated in terms that a user should understand (e.g., tools, toolkits, etc.) This may then get the attention of users.

   A more general concern is that this project will only be successful if the major software vendors are involved. Given that they have their own interaction models, how likely is it that such involvement is forthcoming. I can almost hear them saying "why bother with this project, if you want to interact with our system you can do it by using our toolkit". What is in it for the major players?

3. I'd like to see the emphasis of standardizing interaction for the sake of interoperability being on the definition of standard workflow fragments (e.g., pick a horizon, display contour, select well ) that are most likely to be involved in applications interaction. There should then be a tabulation for those workflow fragments of the common data objects used, and the definition of "state" requirements associated with each of them, such as "active and being edited" or "static" or "inaccessible" etc., with a simple and robust superset that allows rapid implementation for simple cases.

   Data selection lists need to be taken into account.

4. For some while, OMG's business objects group has been working on the problems stated in section 2 and expanded on in section 3 of the RFC. This is not an easy problem set. Since the May 1997 issue of the POSC RFC on Interoperability and Business Objects, OMG has made considerable progress in this area including the finalization of a workflow specification and an evolving a Components Implementation Framework (CIF) which includes a Components Implementation Definition Language (CIDL).

5. As part of the solution concepts it would have been useful to clarify which requirements are already covered by other standardization efforts (you mentioned OMG and WfMG) and which are specific to the EP industry.
6. We believe that establishing an interaction framework will be a critical factor in order to successfully deliver robust applications based on distributed objects to users. Even though the currently defined BO interfaces deal primarily with data objects, client applications have to address the interaction problem. If our goal is to extend OpenSpirit to include processing objects and user interface components, now is the time to sort out important architectural components like interaction.
7. The consensus of responses from the POSC membership to the Intereoperability and Business Objects RFC indicates the target of achieving the capabilities of Level 3 within the next two to three years. This RFC addesses level 5 application interoperability. Since the POSC Interop group is by contrast focused on level 3 interoperability (applications can share process and presentation objects/servers giving plug-and-play for process & data objects and standard look & feel for presentation objects), it might be more useful to confine early discussions around understanding, as only somewhat suggested in the "Call to Action", to questions or issues related and helpful to achieving levels 1-3: for example, does it make sense to think of events as only associated with business objects? Do we not need to have a more complete understanding of the universe of business objects and events, as well as the applications that run in this space, before we tackle the kind of detailed interaction model of sharing and rules for user-programmed applets described here? This is similar to understanding the datatypes--int--and functions that can be performed on these datatypes--addition (level 3)--before describing the sharing and visibility rules for user-programmed applets (level 5) -- what can be passed between calls and called procedures.

   Another one of these early issues deals with a user domain work model. The RFC's proposed next steps begin with an application interaction behavior model that describes how applets/applications should manage interaction. This seems to put the cart before the horse -- with some sort of a work model (or piece of a work model) needed that understands and specifically describes and illustrates the way users or asset teams want to work or actually work before attempting to define a behavior model that's designed to support this. For example, for a suite of applications involving survey/trajectory editing and log display on seismic section, what actions do users perform (said another way, what events make sense to model)?

Identification of Resources
Reviewers were asked to identify resources that their organization (or suppliers, customers, partners, etc.) can make available to work on defining application interaction specifications as part of the overall POSC Interoperability Specifications.

1. [company] can participate in the analysis of RFC comments and/or proposals, and can attend workshops when held in Europe. Due to resource constraints, [company] will not be in a position to steer the initiative.
2. [company] cannot offer resources for free, apart from the occasional critique of any documentation. [company] would be happy to help facilitate the process if funding were made available for us to do so.
3. [company] would be keen to work with any seismic interpretation vendor on dynamically linking our interactive basemaps to their interpretation screens.
4. As POSC and [organization] have had a collaborative relationship for a long time, POSC already knows that all technical work in [organization] is done by the members. As [organization] is already working in this area, combining resources to increase the critical mass of both users and vendors for this work may be feasible.
5. [company] cannot make available direct resources, but we can participate actively in workshops or we can act as reviewer of some deliverables.
6. Not indicated
7. Not indicated

1. [company] defined IDL for the interaction objects described in the RFC. An implementation is operational with the [product] framework used in [company's] new product-line. We can consider providing this IDL if:
   • There is a strong take-up by membership, and in particular by large vendors;
   • The scope defined out of the Interaction RFC does include [company's] own scope;
   • An implementation plan is taking place in an open environment like OpenSpirit Phase 1.
2. Not relevant to [company]
3. [company] is currently building a new suite of data classes which have a particular emphasis on geological and geophysical objects. The aim of this development is to provide interoperability between [company's] surface computation and mapping software and third party interpretation sources on the one hand and visualization tools on the other hand.

   Our current preference is to implement the physical links using OMG technology, but we have to take our significant and growing Windows user base into consideration.

4. Current OMG work in this area is indicated above. Participation of POSC members would be welcome. A list of upcoming OMG meeting can be found at www.omg.org/techprocess/meetings/upcoming.html.

5. We can provide use cases to illustrate, or demonstrate with some limits, expected behaviors.

6. Not indicated
7. Not indicated