From keld@ptah.dkuug.dk Wed May 3 03:12:57 2000 Received: from mail.dkuug.dk (IDENT:keld@104.ppp1-23.worldonline.dk [212.54.81.104]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id DAA72978 for ; Wed, 3 May 2000 03:12:54 +0200 (CEST) (envelope-from keld@ptah.dkuug.dk) Received: (from keld@localhost) by mail.dkuug.dk (8.9.3/8.9.3) id DAA03911; Wed, 3 May 2000 03:11:34 +0200 Date: Wed, 3 May 2000 03:11:33 +0200 From: =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= To: Nick Stoughton Cc: "'SC22WG15@dkuug.dk'" Subject: Re: (SC22WG15.1494) Summarizing WG15 AIs for Reading meeting Message-ID: <20000503031133.A3888@light.dkuug.dk> References: <200005022229.AAA72426@dkuug.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <200005022229.AAA72426@dkuug.dk>; from Nick Stoughton on Tue, May 02, 2000 at 03:29:42PM -0700 On Tue, May 02, 2000 at 03:29:42PM -0700, Nick Stoughton wrote: > Here is a proposed DoC to go into the May meeting with. I would like to ask > all MBs to consider whether they would support this DoC. I appreciate that > we now have less than 2 weeks until the meeting, and therefore this is not a > formal letter ballot, I'm just looking for guidance as OR. I think we should not reduce all of the WG15 input to just one voice, the arguments should have the possibilitiy of being dicsussed in the open by the Austin group. Anyway I welcome discussion here. > > 1. The documents are not recorded as ISO/IEC standards, but rather > > listed as IEEE Stds. This is unacceptable. A common denomination, > > such as POSIX-1 and POSIX-2 Std should be adopted, with a > > definition in the terms and definitions section, that this > > denominates the ISO/IEC, IEEE and X/Open standards. > > The documents are developed under a joint Memorandum of Understanding > between IEEE and The Open Group. The JDOCS procedures call for all three > bodies to work in collaboration to develop the standard, with all material > being freely shared between them for the purposes of standardization. It puzzles me that the joint memorandum has not included ISO and IEC in the agreement. > Upon > adoption as an ISO standard, the document will be printed and presented > in a similar way to that used for the current editions of 9945 (that > is to say, they will carry ISO/IEC, IEEE and The Open Group logos and > information on the front cover, and will use a macro that expands to ISO > 9945 instead of SUS or IEEE designations internally. This is not what we want, and actually not even what we have done in the past between ISO/IEC and IEEE. ISO/IEC and IEEE has published the *same* document. And that is the plan also for the new common spec. > Additionally, this > revision combines the previously subdivided standard into a single standard, > 9945. It is intended to replace both 9945-1:1996 and its supplements, > and 9945-2:1992 and its supplements. The new standard will be published > in four volumes: Base Definition, System Interfaces, Commands > and Utilities, and Rationale. If we use the numeric designators POSIX-1 > etc, then POSIX-1 == XBD, POSIX-2 == XSH, POSIX-3 == XBD and POSIX-4 > ==XRAT. This will be extremely confusing for people in the transition > period, when POSIX-2 can be thought of as referring to either the old > commands and utilities, 9945-2:1992 standard, or the new XSH volume. > Therefore, the names POSIX-1 and POSIX-2 are now inappropriate for > referring to the internal volumes of the single standard. I can accept this. > > > 2. There is no indication of ISO/IEC participation. This is not > > acceptable. ISO/IEC should be listed on par with IEEE and X/Open. > As previously stated, upon adoption by ISO, these standards will gain the > ISO attribution appropriately. This is no different to existing > drafts in development by PASC. Please note that participants are ISO/IEC, > IEEE and The Open Group; X/Open should not be listed anywhere. Please substitute "The Open Group" for "X/Open", mea culpa. Please use the term ISO/IEC for that international partner. The arrangements that we have done says that we will publish one document only, and that also the TOG and IEEE specs will have appropiate ISO/IEC copyrights and notations assigned. > > > 3. The drafts are not drafted according to JTC1 directives. > > This is needed for it to become an ISO/IEC standard. > > Clauses must match the JTC 1 directives. This seems only > > to be a matter of clause numbers and should not change the text per se. > > Non-normative references should be moved to a "Bibliography" section. > The current document editors have worked closely with the IEEE staff editors > to ensure that all the appropriate JTC-1 directives and guidelines are being > met. While the draft is laid out in a different style than that normally > used for ISO written documents, it is very much in keeping with the recent > JTC 1 initiatives in increasing relevance, typified by JTC 1 N6051 > (Denmark), > entitled "Meeting current market requirements without seeking > perfection". The current style is adequate for this document to become an > ISO/IEC standard. I dont think so wrt the use of terms like "This International Standard". > The consensus of WG15 is that clause numbers are not > required beyond the level that they are currently used. That is probably OK by me. > > It is also worth pointing out that PAS submitted documents have become > ISO/IEC standards without adopting any of the ISO style rules. We are not talking about PAS here, but a normal ISO/IEC standard developed in the normal 5 stage ISO/IEC development procedure. Furthermore, all the PAS standards I know of were adopted for JTC1 style in the PAS approval process. > > 4. Should page numbers be added, we prefer these not to be in the > > running text, but eg in the margins. We note that for publication > > in HTML the page numbers are not meaningful. > > Several other National Bodies have requested in-line page numbers (UK, US > and Canada) if page numbers are permitted in cross references. The Norwegian > > input is gratefully received, but it is believed that marginal page number > cross references would in fact reduce the current level of consensus on > this subject. Since these page numbers are automatically generated by the > software, they can also be removed when converting to HTML without changing > the semantics of the reference. Why would it reduce concensus? It would be easy to do it in the margins or at the buttom. > > > 5. There should not be any differences between the ISO/IEC > > standard and the X/Open specification nor the IEEE Std. > There will be one standard produced. The standard will carry the names and > logos of all those organizations that adopt it (ISO/IEC, IEEE and The Open > Group). The resulting standard will be an Open Group specification, not > X/Open, > as well as ISO/IEC and IEEE. Good! > > > 6. We see no need to change the title of the standards, > > so eg. the title "shell and utilities" should be retained for > > part 2 of 9945. > The project is to revise and combine the two existing standards into a > single > standard. There will be no "part 1" and "part 2" in the result. For > publishing convenience (and user convenience!), the resulting standard is > expected to be printed in at least 4 volumes, as described above. Various > material is moving around from its original place in the two parts of 9945 > to a new position in one of the four volumes of the new single document. > Therefore, a title such as "System Interfaces and Headers" is believed to be > more useful to the end user than "System Application Program Interface". > However, no other National Body has commented on the titles, and thus > Title changes should be discussed on the agenda of the next Austin Group > plenary meeting. OK. > > 7. The references to ISO/IEC C99 material needs to be resolved > > satisfactorily with SC22/WG14 and ITTF. > The next draft, including all the new c99 material, will contain explanatory > notes and normative text explaining that this material is derived from > ISO/IEC 9899:1999, and deferring to that standard in the case of conflict, > unless the interface is explicitly extended. The Austin Group has formally > requested input from WG14 on this issue. Some response have been given from WG14, but WG15/Austin has not taken it into account. Keld