• Objective: define standard interfaces for visualizing OpenSpirit data based on OMG Corba and OpenSpirit 2d graphics.
• Team: 9 people
• Duration: 6 working sessions lasting a total of 7 work days.
• Experience: Most have 3d viewer experience. Most do not have prior CORBA experience.
• Status: A first draft has been completed. There is room for many improvements.
• Open Issues: software license requirements for viewer developers, completeness, stability, review within OpenSpirit, submissions to POSC.
• Future Items: more visuals, more event handling devices, data duplication / sharing, cross-vendor interoperability, remove collaboration support, visual capabilities using CORBA properties, 3d utility classes, sub-menu support, and more.

General Q&A:

• How difficult will it be to implement a viewer? Answer: Two vendors with CORBA experience (but no OpenSpirit experience) plan to have prototypes ready at SEG 99.
• Comment: Some viewer developers have expressed concern about the expense (money and resources) needed to acquire and install vendor data store development kits (e.g., for OpenWorks and GeoFrame) in order to test their OpenSpirit compatible viewer products. They would like there to be OpenSpirit data servers that run over simple (ASCII) files so the vendor data store development kits would not be needed at all.
• Is there a separate requirements document? Answer: No. The requirements can be discerned from the working meeting minutes. Comment: The requirements and non-requirements must be extracted to highlight the context, dependencies, basic boundaries of capabilities, etc.
• Comment: The OpenSpirit eRoom should be considered to host discussion on the draft specification.

Viewer Q&A:

• Has stereo capability been addressed? Answer: Yes. There is a stereo viewer property. Stereo-capable hardware is also required, though.
• Has screen splitting into four parts been addressed? Answer: Multi-pipe capabilities were not addressed. One screen / window can be handled.
• A life cycle approach to viewer creation should be considered.

Layout Q&A:

• Comment: We should be able to emulate the style of a vendor product by controlling aspects of layout.
• Has the attachment property been defined? Answer: No. This can be added with an extended layout manager. In general, vendors can define additional properties. We did not define how such properties can be rolled into the "standard" set.
• Comment: The dividing line between things that are defined and things that are delegated for implementations to define should be defined.
• Is there a capability for an applet to determine the features supported by the available hardware? Answer: A viewer can be asked about the features it supports. The availability of a specific visual, e.g. for voxels, indicates that the associated feature is supported.
• How many visuals are involved if a stacking chart is placed across a seismic section? Answer: Two. There is a stacking chart visual in 2d and a section visual in 3d.

Properties Q&A:

• Is the "view type" a short-cut for a list of supported visuals? Answer: Yes. A query can be issued for the available view types, e.g. you may ask whether there is a viewer from the ABC company with a 3d view.
• Comment: The direct use of the OMG Corba Property service should be considered. A subset of the properties can be made available in the Trader service for query.

View Q&A:

• What coordinate system is used with view attributes? Answer: The coordinate system used is specific to each attribute.
• Has output to hardcopy devices been considered? Answer: No, not explicitly as far as defining hardcopy-specific attributes and parameters, print scaling, etc.
• Is "polyline" defined as a visual? Answer: We debated whether to define only a small number of primitive visuals to which others can be mapped. We decided not to do that, but we anticipate that some implementations will factor out primitive visuals.
• Is the OpenSpirit "sampled data" (i.e. Shape, etc.) supported? Answer: No, but the document says that it can be added.

Event Type Q&A:

• Howard: This will be covered in greater detail in the application interaction initiative. What is defined in the document is very limited and there is a lot of room for improvement. More requirements must be considered.
• Was XML considered? Answer: XML was discussed late in the project, but it was not addressed.

Menu Q&A:

• Howard: This will be covered in greater detail in the application interaction initiative. Only one level of menu is supported. This should be extended.

Closing General Q&A:

• Howard: It is important to identify anything in the document which will inhibit making extensions to the specification where needed. Backward compatibility is important once implementations are begun using the specification.
• Comment: There should be a separate requirements document.
• Comment: Some functionality documented as distributed interfaces in OMG IDL should be converted to local functionality specified in another manner.
• Can new visuals be added? Answer: The lower level protocols needed to ensure the ability to mix new visuals with existing ones have not been defined adequately.
• Is the specification limited to live user sessions? Answer: This is its orientation, but it is not an absolute limitation. Data and property change events, for example, need not be related to live user interaction.
• Comment: This project was a good assembly of qualified 3d graphic experts. Another cycle of work is needed to complete and integrate this work.