From djblackwood@attcanada.net Wed May 3 03:16:41 2000 Received: from mailhost1.attcanada.net (mailhost1.attcanada.net [206.191.82.42]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id DAA73002 for ; Wed, 3 May 2000 03:16:40 +0200 (CEST) (envelope-from djblackwood@attcanada.net) Received: from home ([142.194.244.52]) by mailhost1.attcanada.net (InterMail v03.02.07.03 118-128) with SMTP id <20000503010732.UOD6282@home>; Wed, 3 May 2000 01:07:32 +0000 From: "D. J. Blackwood" To: "Nick Stoughton" , Subject: RE: (SC22WG15.1494) Summarizing WG15 AIs for Reading meeting Date: Tue, 2 May 2000 21:16:30 -0400 Message-ID: <000401bfb49d$3687d540$34f77018@flfrd1.on.wave.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <200005022229.AAA72426@dkuug.dk> I share some of Norway's concerns with respect to attribution and style issues but I am confident that these will resolve themselves in due time. However, since ISO can be particularly recalcitrant when it comes to accepting change, it might be wise to raise some of these issues with them now rather than risk introducing delays at a later, more critical stage of the process. However, I believe that the position as you have stated it fairly represents the consensus of WG15. Dave > -----Original Message----- > From: owner-cac-jtc1-sc22-wg15@www.scc.ca > [mailto:owner-cac-jtc1-sc22-wg15@www.scc.ca]On Behalf Of Nick > Stoughton > Sent: May 2, 2000 18:30 > To: 'SC22WG15@dkuug.dk' > Subject: (SC22WG15.1494) Summarizing WG15 AIs for Reading meeting > > > > > > > At the upcoming Austin Group meeting in Reading, I will be providing > responses to two action items from the last WG15 meeting for > Austin Group > consideration. Since we have multiple responses, I would like > to solicit > guidelines and opinions on how best to present these. > > 9907-15 (Member Bodies): Provide input to REV on any implementation of > alternative command syntax for the "dd" command. > > Responses received from UK, Canada, Norway and US. > > NO: we have no further input on this matter. > UK: The UK has no suggestions for an alternative command > syntax for the > dd command, and is happy with the current specification in 9945-2. > CA: We (Canada) have no input to offer on either of these > action items. > > US: Based on consultation with the development body, yhe U.S. > has no further > input to this action item. > > So, I think this one is pretty easy: don't do anything! > > 9907-21 (Member Bodies): Review and comment regarding Style > Issues arising > from draft 1 of the Austin Group revision document. > > CA: We (Canada) support the addition of > page numbers in printed (or other "paged" representations such as PDF) > versions and hypertext links in electronic (*ML) versions of > the documents. > However it would be desirable if these were maintained > automatically rather > than manually and it would not be desirable to have either embedded > hypertext links in printed versions or page numbers in online > (*ML) versions > as these could confuse the reader and impair readability. It > appears from > the wording of the proposed recommendation that "page number ... cross > references ... must be correct in any alternative > presentations" which could > be interpreted to include an online HTML presentation where > they would be > inappropriate." > US: The U.S. is continuing to discuss Style Issues > related to the Austin Group draft document will raise issues > and comments > as appropriate. > UK: The UK is satisfied with the style currently proposed by the > "Austin Group". The UK believes that page number citations in cross > references are extremely useful and valuable, however the UK > will not object > if they are absent". > NO: There are a number of unresolved issues with the Style > as recorded in the 2000-02-29 Austin drafts: > > 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. > > 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. > > 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. > > 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. > > 5. There should not be any differences between the ISO/IEC > standard and the X/Open specification nor the IEEE Std. > > 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. > > 7. The references to ISO/IEC C99 material needs to be resolved > satisfactorily with SC22/WG14 and ITTF. > > > This one is obviously going to be harder to summarize: > as I see it, the UK is happy with the current style, and > would like to see > page numbers in cross references. Canada wants page numbers in cross > references. The US has no current issues with the style, but > will continue > to comment as necessary (as I hope will all member bodies). > Norway stands > alone in having several substantive objections to the style. > I would like > other member bodies (if there are any listening!) to comment > on Norway's > position. If we take the actions described here, will these > introduce new > objections? > > 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. > > > 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. 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. > 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. > > > 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. > > > 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. The consensus of WG15 is that clause numbers are not > required beyond the level that they are currently used. > > It is also worth pointing out that PAS submitted documents have become > ISO/IEC standards without adopting any of the ISO style rules. > > > 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. > > > 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. > > > 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. > > > 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. > > > -- > Nick Stoughton > Webvan Group Inc Usenix Standards Liaison > 650 627 3277 510 366 6176 (cell) > > >