Minutes from ASISWG/ASISRG Meeting of 26-27 June 1995 in McLean VA, USA The Ada Semantic Interface Specification Working Group (ASISWG) and the Ada Semantic Interface Specification Rapporteur Group (ASISRG) met at the Speical Interest Group on Ada / Washington Ada Symposium (SIGAda/WAdaS'95) in McLean, Virginia, USA. ASISWG/ASISRG met all day Monday and Tuesday (26-27 June) at the Hilton Hotel in McLean, VA, as part of SIGAda/WAdaS'95. The following people attended: Steve Blake, Thomson Software Currie Colket, SPAWAR Dan Cooper, Boeing J.C. Morris, Ada Solutions (part of meeting) Dan Rittersdorf, Harris Computer Systems Corporation Clyde Roby, IDA Mark Schulte, McDonnell Douglas (part of meeting) Bill Thomas, MITRE The primary goal of this meeting was to finalize the Ada specification for ASIS 95; several drafts had already been brought before ASISWG for review; Draft 2.0.B was reviewed by ASISWG at this meeting. We're almost done with design issues for ASIS 95. We hope to have a review by OO experts within 2-3 months. The minutes of the March 1995 meeting were accepted and approved by a formal motion and vote. ISO Standardization of ASIS This meeting represented the first joint meeting of ASISWG and the newly formed ASISRG. On 28 April 1995, ISO/IEC JTC1/SC22/WG9 unanimously voted to pursue the standardization of ASIS. A New Work Item (NWI) will be submitted to SC22 for formal approval in September 1995. At this June meeting of ASISWG/ASISRG, the roles of ASISWG and ASISRG were discussed as was the wording for the ASISRG New Work Item. ASISRG will standardize ASIS as a stand alone international standard. Currie Colket, who was present at the WG9 meeting, told ASISWG/ASISRG that once the NWI moves up the chain of command, it is very difficult to change. Thus, we must carefully determine its content. Currie suggested that SC22 usually approves NWIs which come from its WGs. Currie then explained that the Annex H Rapporteur Group (HRG), the Safety and Security Annex group, has developed a formal charter to define a "safe" subset of Ada. They are using three techniques, one of which uses ASIS. The HRG is led by Brian Wichmann of the UK. The US is represented on WG9 by the AJPO, currently in the person of Christine Anderson. As of this June meeting of ASISWG, ASISRG has only representation from the US. We are currently looking at ways to involve other interested parties from other nations throughout the world. Currie noted that Sergey would like to organize an ASIS meeting at Ada Europe later this year in October; this would be an excellent opportunity to move ASISRG forward in the international community. The members of ASISWG and the members of ASISRG are currently the same group of people. ASISRG has two official officers: Chair of ASISRG: Currie Colket of US Co-Project Editors: Steve Blake & Clyde Roby, US ASISRG can have other officers if the need is warranted. Note that, as ASISWG, individuals represent their organizations, but as ASISRG, individuals from the same nation represent one vote for that nation. Thus, everyone present at the June 1995 meeting of ASISRG represented the US position (only one vote). Note that nothing was voted on at this meeting of ASISRG. Much email discussion from international participants was factored into the outcome of this meeting. International participants are highly encouraged to participate in the discussions by email and in person. Countries currently supporting ASIS include: Australia, Canada, Denmark, Germany, Japan, Russia, Switzerland, UK, and the US. ASISRG New Work Item for WG9 The proposed New Work Item (NWI) was distributed for comment. We are aiming to deliver a Committee Draft of ASIS in December 1995. This can be some filled-in template information plus compilable source code with embedded comments. There followed some discussion on the schedule (see below). We will not send ASIS 83 V1.1.1 to ISO for the Committee Draft. We will try to have the ASIS 95 document ready to send to ISO for the CD; this same document will be distributed at/after Tri-Ada'95. Expected ASIS Schedule for ISO Standardization Currie distributed ISO/IEC 11729 as an example generic package of primitive functions of Ada -- for Ada 83. It is an example of the format that WG9 has accepted in the past. We can probably use some boiler-plate information contained in this document for the document we will eventually develop for the standardization of ASIS 95. The New Work Item (NWI) will be submitted in September 1995 to SC22. We will currently need a lot of commentary for ASIS 95 for inclusion in the ISO document as ASIS 95 moves forward for standardization. Steve would like to distribute ASIS 95 package by package (or small groups of packages) to ASISWG for review. In this manner, we still might have something to distribute for Tri-Ada'95 in early November. As can be seen by the following schedule, we are still looking for an ISO approved standard ASIS 95 in the 1997-98 time frame. Dec 93 AJPO recommends ASIS V1.1.0 (ASIS83) be used as interface to Ada83 Program Library Mar 94 Design Goals for ASIS95 identified Jun 94 ASISWG finalizes ASIS83 as V1.1.1 with test suite Jun 94 Evaluate design approaches for ASIS95 Nov 94 Finalize approach for ASIS95 Nov 94 Categorize outstanding ASIS 83 deferred issues Nov 94 Proposed KINDS for ASIS95 Feb 95 ASIS Home Page on WWW established http://www.acm.org/sigada/WG/asiswg/asiswg.html Mar 95 Finalize ASIS95 Kinds Mar 95 Provide ASIS95 in Skeleton format Mar 95 Organize ASIS83 Deferred Issues and Current Issues Apr 95 ASISRG created unanimously by ISO/IEC JTC1/SC22 WG9 Jun 95 Approved initial ASIS95 Element_Kind Type Hierarchy Jun 95 Approved changes to ASIS83 to produce ASIS95 draft standard Jun 95 Defined ASIS terminology Jun 95 Approved new library/environment model Fall 95 Public Review of ASIS95 Fall 95 ASISWG vote to submit ASIS95 as ISO Committee Draft Fall 95 ASIS available for GNAT Ada95 Compiler Fall 96 Balloting complete for ASIS95 Proposed Draft IS Jun 97 Balloting for ASIS95 Draft International Standard 1997-98 ASIS95 approved ISO Standard ASIS and the Internet The following new information is now available on the ACM host machine via the World Wide Web as HTML pages: * the ASIS Frequently Asked Question (FAQ) list * ASIS Vendor Products * ASIS Related Work * ASIS Tutorials (soon from Rational and Thomson) * information about ASIS for GNAT * other information about ASISWG and its meetings, etc. The URL is: http://www.acm.org/sigada/WG/asiswg/asiswg.html The following ASIS, ASISWG, and ASISRG artifacts are located on the AJPO's host machine (sw-eng.falls-church.va.us) in the /public/adaic/work-grp/asiswg directory: /public/adaic/work-grp/asiswg directory README ASISWG-Charter (most recent charter) ASISWG-Charter-proposed ASIS-FAQ.txt (ASCII of ASIS FAQ) ASIS-FAQ.ps (PostScript version) ASISWG.archive (email archive to ASISWG) ASISWG-Technical.archive (email archive to ASISWG-Technical) asiswg-members (list of ASISWG members) /asis README asis-pvl.tar (ASIS Program View Layer software) /bibliography README (text of recent ASIS/ASISWG articles) /issues README ASIS83-Issues-Summary (issues from ASIS 83 for consideration in ASIS 95) Comment-Submission (how to submit a comment) Issues-Summary (one-liner for each issue) /issue001 README (link points to issue001 file below, not directory above) issue001 (contains text of issue) (other supporting files as needed) /issueNNN README (link points to issueNNN file below, not directory above) issueNNN (other supporting files as needed) /V1.1.0 README (Ada sources of specification, zipped) /V1.1.1 README (Ada sources of specification, zipped) /tests README (tests as appropriate; .list and .zip) /toolkits README (for each toolkit) (.tar and .Z files for each toolkit) /V2.0.0 [note: most of this directory is currently empty] README (Ada source of specification) /examples README (examples as appropriate) /tests README (tests as appropriate) /tookits README (examples of toolkits applications as appropriate) /meetings README (action items) (decisions) (minutes) (goals and schedule) It should be noted that the .../examples and .../tests subdirectories will exist only when actual examples and tests exist. Terminology Issues Between March and June, there have been several email messages on the ASISWG-Technical email discussion list concerning terminology. Dan Cooper has done an excellent job of analyzing the discussion and will send out an updated email message based upon the discussions ASISWG had at this June meeting. There was a great deal of time spent at this ASISWG meeting ironing out an understanding of the meaning of words and phrases ASISWG uses as a group in discussion. This went a long way toward helping us broaden our scope and change direction slightly. The agreement to use RM 95 terminology and not conflict with its definition was important in removing some of the confusion we had previously encountered when discussing ASIS. Sergey Rybin of Russia has been asking questions about the Ada 95 Library and has received excellent responses from others within ASISWG. Many of Sergey's questions have brought up other issues for ASISWG to discuss. It there a value for a strictly source-based ASIS environment? If so, then we should make some recommendations about how to use it and what the limitations, if any, are. This prompted further discussion at the meeting. ASIS queries should be implementable even if the information is retrieved "on the fly" (e.g., a source-based environment). A valid implementation of ASIS would not need to know anything about the Ada compiler implementation details. ASIS, seen as a query interface, extracts the information it needs either from a "library" created sometime in the past, or it may extract the information "on the fly" (e.g., a source-based environment). There was much discussion about how this relates to GNAT-ASIS. In a sense, GNAT creates a program library, but it is not kept around in a persistent library as traditional compilation systems do. We want to get away from the traditional library as the limitation on which ASIS will operate in order to get its information. What do we call what ASIS really is? One suggestion is a Query Analysis Server. The focus of ASIS is the Ada environment as defined by the Ada 95 Reference Manual (RM 95). It is not constraining information literally as in an Ada source, but we do constrain it to be semantically equivalent to the Ada source. ASIS will return semantically equivalent syntax (not necessarily the exact literal syntax of the Ada source). ASIS should be focused more on the semantics rather than the syntax -- thus letting other syntax programs focus more on the syntax of an Ada 95 program. Focus on the semantics of the Ada environment first, then on the syntax of the compilation units. What does ASIS interface to? ASIS interfaces to an Ada environment implementation. Does ASIS interface to a library or to an environment? Ultimately, ASIS interfaces to the Ada sources. But we must define in the documentation about ASIS what the "object" is and thus we can define what ASIS interfaces to. In RM 95 (10.1.4(9)), the use of the term "library" seems to relate to an implementation. What this section discusses is an Ada environment. ASIS should be an interface to multiple Ada environments (as defined in this RM 95 reference). Note that RM 95 (10.1.4(3)) indicates that an Ada environment is implementation-defined. ASIS is an interface to Ada environments. An ASIS server handles queries from the client (tool) to obtain information from the Ada environment. We will try to clear up the following terms as we discuss ASIS and related topics in the future. "Vendor" will be replaced by "implementation" or "provider". "Vendor-independent" will be changed to "non-proprietary". We no longer have primitive/primary interfaces and secondary interfaces; we just have ASIS interfaces. "Secondary-layer" now is "toolkit". Among ASISWG-Technical, "primary" means to define ASIS queries that access implementation-dependent information. There was further discussion about Dan Cooper's email message of 18 May 1995 which contained 10 items/questions for discussion and answers. Dan plans to take everything from the discussion we had at this meeting about these issues and formulate another email message to be distributed to ASISWG-Technical. We want to keep knowledge about all implementation approaches around. Any ASIS specification should not preclude any of these approaches. Although levels of conformance cannot be addressed until the ASIS 95 specification is better defined, preliminary conformance issues were discussed. A minimum capability would support the environment semantics providing an external (black box) view of Ada compilation units. This implies full support of the packages ASIS_Environment, ASIS_Libraries, and ASIS_Compilation_Units. These packages are being modified to support the new concept of the ASIS Model of the Ada environment and support of the minimum conformance requirement. Other degrees of conformance may be based on the ease of implementation, classes of semantic information for views internal (white box) to the compilation units, and support of data decomposition. Levels of conformance are related to the ease of implementation as well as the types of things that users want to have implemented. ASIS Model of the Ada Environment As a result of the previous discussion, the ASIS 95 Model has changed to support the changes from Ada 87 to Ada 95. Ada 87 had notions of a library, compilation/recompilation order, and obsolete units; Ada 95 replaces these notions with an Ada environment, semantic dependencies, and a consistent set of the supporters of a unit. ASIS has thus been redefined as follows: The Ada Semantic Interface Specification (ASIS) is an interface between an Ada environment as defined by ISO/IEC 8652 and any tool requiring information from this environment. An Ada environment includes valuable semantic and syntactic information. ASIS is an open and published callable interface which gives CASE tool and application developers access to this information. ASIS has been designed to be independent of underlying Ada environment implementations, thus supporting portability of software engineering tools while relieving tool developers from having to understand the complexities of an Ada environment's proprietary internal representation. Earlier ASIS definitions assumed the presence of persistent data in a heavyweight Ada program library. The current definition has no requirement to maintain persistent data and thus facilitates the Ada 95 GNAT compiler ASIS implementation which maintains little persistent data in the environment. Formal Issues discussed at this ASISWG meeting #001 and #002 updated with Steve's email message from the week before the meeting. #003 - Dan Rittersdorf will send Clyde an updated issues list to upload to the AJPO host. #005 will leave open for probably another meeting or two; this concerns the conformance to what is implemented or not included in the specification [two levels of conformance: textual (literal) and semantic]. #008 will be reorganizing the ASIS structure to reflect degrees of conformance; also, even in Element_Kinds there is more hierarchy -- lacking further proposal from Dan Ehrenfried, we closed this issue. #009 we are less preclusive than before; this issue is based upon defining a non-proprietary protocol; this should be in the Implementation Permissions section of an approach document before this issue is closed out. Ada 83 or Ada 95 specification for ASIS? There was some discussion about whether or not the ASIS specification should be defined in Ada 95. We basically agreed that it should be. Ada 83 conformance could be another conformance level (see previous discussions), i.e., an allowable conformance mainly using RENAMEs. The main feature of Ada 95 that we will use is the parent-child package structure. We will try to keep the rest of the specification in Ada 83. ASISWG will define the Ada 83 specification at some point in the future. We recorded the above as a Decision of this meeting. The promise to keep further Ada 95 features out of the specification is a pretty firm one. We agreed that a corresponding Ada 83 specification would be maintained, for the time being, that provided similar structure using RENAMEs for items from other library level packages. It is still important to keep an Ada 83 compatible specification in this transition period, when not all compilers are up to full Ada 95 support, and each is approaching full support from a different direction. ASISWG Charter The charter was distributed again for review. Two significant events have required that changes be made to the charter. The first is the focus or scope of the ASIS specification. The second is the ISO standardization of ASIS, which is being worked on by both ASISWG and ASISRG. The updated charter will be distributed to ASISWG soon for further review and comment. After that, the proposed charter will also be placed on the AJPO host as well as the WWW node. ASISWG/ASISRG Officers As of this meeting, ASISWG's officers are: Chair: Currie Colket Vice-chair: Steve Blake Recorder: Clyde Roby Vice-recorder: Dan Cooper Publicity/Meetings: Bill Thomas and ASISRG's officers are: Chair: Currie Colket of US Co-Project Editors: Steve Blake & Clyde Roby, US We would like to thank Gary Barnes of Rational, who has served as the ASISWG Archivist, for his important work in maintaining the records for ASISWG. This responsibility was vitally important in our growing years and helped identify those activities necessary to automate. Much of the archiving activities have now been automated in our transition to the World Wide Web. Finalize ASIS 95 Specification The work on finalizing the ASIS 95 specification consumed most of the afternoon Monday and nearly all day Tuesday. Steve Blake had prepared some handouts from which the discussion was based. Many of the comments from the last ASISWG meeting had been incorporated in the Version 2.0.B of the ASIS specification presented at this meeting. As we discussed Steve's handouts (Draft 6 changes from Draft 5), several (minor) changes were identified. * All references to the Ada 95 Reference Manual will be simply "RM 95". * Trait_Kinds commentary was reviewed. Steve will check the order and the mutual exclusivity. He will consider changing Not_a_XXX to No_Applicable_xxx. Maybe look at changing An_Ordinary_Trait to something else. Perhaps look at a different term for "Trait". * Alternative_Kinds discussion. Move TERMINATE here as a pseudo-statement; what are the effects of doing this? Most of Sergey's comments can be cleaned up with better commentary. But will revisit Alternative_Kinds again as there is currently some discomfort with the current structure/break-out. * There should be a usage explanation at the beginning of each package; it should basically follow the RM 95 syntax, not necessarily the concepts. * Unit_Kinds discussion. This was expanded to be more specific. Corrected subtype A_Subprogram_Body and added subtype A_Library_Unit_Body and added subtype A_Renaming. Change A_Procedure, A_Function, A_Package to An_Ordinary_XXX. Expand Subunit and make it a subtype. "Protected" is really "Proprietary". Steve will also look at the possibility of other changes. * Unit_Trait_Kinds discussion. * Unit_State_Kinds discussion. Order by the states it would transition through. Will add references to RM 95 for consistent and inconsistent in 10.1.4 and 10.1.1(24). Add unknown state for other language units, for example. There was a related discussion about proprietary units (implementation dependent units that an implementation doesn't want users to see). There was also a discussion about foreign language units. There was some discussion about black-box (proprietary) as well as foreign language units; how consistent/reliable is the thing that is analyzable? Unit_State_Kinds applies to Ada compilation units, not non-Ada stuff. The issue is that, although a unit is unknown, there is some information that is available, depending upon how much the implementor wishes to let known about it. Remove A_Nonexistent_Unit. Note that An_Unknown_Unit of Unit_Kinds can have any of the values of Unit_State_Kinds. Change the suffix to _State instead of _Unit. * One of Sergey's questions concerned exceptions. Should exceptions be declared in a separate package within ASIS? The current thinking is to put exceptions in an ASIS top-level package with a renaming of them. Type Error_Kinds should be in the same package as the exceptions. Document the mapping of Error_Kinds to the proper exceptions. * Unit_Origins discussion. Change A_Compiler_Predefined_Unit to An_Implementation_Predefined_Unit. Issue about adding A_User_Predefined_Unit (for other environment's package SYSTEM and STANDARD). Change A_User_Defined_Unit to Not_A_Predefined_Unit. We also reviewed the proposed version 2.0.B of ASIS 95. Appendix C describes a list of changes since 2.0.A. Some of the areas we discussed at this ASISWG meeting include: * 3.5. Body_Block_Statement replaces three function calls. Sergey has some good reasons to the three different calls back in, though. Steve will write rationale for the one routine instead of the three routines. Since Bob Hokanson indicated that he wanted it, Steve will try to get in touch with him and find out why. Steve will look into the possibility of putting the 3 calls back in; perhaps at a toolkit level. * Section 4. Will need to add terminology, especially about Ada environment, Ada library, etc. The subprogram Semantic_Dependence_Order replaces three subprograms, but these will be rewritten in terms of Semantic_Dependence_Order and placed in the .../toolkits directory. * 4.1. Much of this came from Sergey's email over the last few months. * 4.2 through 4.5. Much of this has been discussed previously in the meeting; the terminology in section 4.5 can be added to the ASIS glossary. * 4.6. More discussion from 3.5 above. Also, get rid of the four unit relationship filter queries; these can be placed at the toolkits level. * Appendix A. Remove the prefix Compilation_ on most of the routines in the ASIS_Compilation_Units package. Move the functions Unit_Declaration, Context_Clause_Elements, and Name_Units from the ASIS_Compilation_Units package to other packages appropriate to where they really belong. There was also some discussion about moving some other subprograms into child package(s) for ASIS_Compilation_Units. Discussion about References subprogram There was a question about whether the References subprogram should be in the ASIS specification or whether it is one of the many things that should be in .../toolkits. It needs to be optimized on the server side as well as the client side. It balances the capability of getting definitions. The question arises about what ideally is a Reference? It is ill-defined. Do we look at implicit along with explicit references? There was general agreement that we should have it. There was some consensus that it should be in ASIS and not in .../toolkits. Ada Letters and ASIS Currie will generate the highlights of this meeting and deliver them to be printed in the next issue of Ada Letters (note that the deadline was July 1). The next issue's deadline should be near the first of September. We hope to have the minutes of this meeting and maybe a Tutorial or a high-level article about ASIS 95 (probably not both). We would also like to have the updated FAQ in the next issue. Future meetings An ASIS Workshop is scheduled on Friday, 6 October 1995, in conjunction with the Ada in Europe 95 Conference. If possible, it would be an excellent opportunity to liaison with Europeans interested in ASIS. There is a "Foundations of Software Engineering" conference 11-13 October in the DC area. Perhaps we could meet on 9, 10, and the morning of the 11th of October? Note that 9 October is Columbus Day holiday. We discussed other meeting times around Tri-Ada'95, too. After further discussion, we tentatively have scheduled: 2-4 November 1995 at Thomson Software Products in San Diego 5-10 November 1995 during Tri-Ada'95 in Anaheim We will have a panel session; there will be no Birds-of-a-Feather session. The panel will have a mini-overview of ASIS 95, including a discussion of how ASIS has been used for developing applications. It will also include information about the ASIS 95 standardization. At a minimum, we would like to distribute the ASIS/ASISWG FAQ. Hopefully, we will have a document to distribute at Tri-Ada, too.