From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Tue Nov 21 19:12:02 2023 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 6891C356B04; Tue, 21 Nov 2023 19:12:02 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from sasl.smtp.pobox.com (pb-sasl21.pobox.com [173.228.157.49]) by www.open-std.org (Postfix) with ESMTP id B3B0A356A61 for ; Tue, 21 Nov 2023 19:12:00 +0100 (CET) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl21.pobox.com (Postfix) with ESMTP id B61491DAB2; Tue, 21 Nov 2023 13:11:58 -0500 (EST) (envelope-from gak@dancingbear.dev) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=sasl; bh=wMqFQ1eb7LVHayWyju/lJfTzhAUPpWzpY5 ch37rI0tI=; b=lKJ168hdtx5lt8pHRR9F6YfqHFZKYEM8jNpDlrjV7TsLOMx3+B J3i4AArZV5cyTbJdkrfSRUQKwJy6spAA1c4c0yc/oW+T25Jk/tm94kqULoGqohvX 1UjZZzIJl+HiZSrd99lmxTqC/BhL+YFe6IPtTRW+65tinGKf4XluIKu44= Received: from pb-sasl21.sea.icgroup.com (unknown [127.0.0.1]) by pb-sasl21.pobox.com (Postfix) with ESMTP id 9F9951DAB1; Tue, 21 Nov 2023 13:11:58 -0500 (EST) (envelope-from gak@dancingbear.dev) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dancingbear.dev; h=from:message-id:content-type:mime-version:subject:date:in-reply-to:cc:to:references; s=2019-12.pbsmtp; bh=wMqFQ1eb7LVHayWyju/lJfTzhAUPpWzpY5ch37rI0tI=; b=WyXuKnNweZUcmPMkqOTmri/pVew76MgFBX8cCYud5iUXHHgfoNVzmflbV846kFc/VJf18K6F8eu+0tHOZGHK2mpTRTDEHEUIWDSSfnY1N8CdO0k6JtGmy3xf9vP5PyRVTcQOWCwW074s9b/uv/aIV3lz1VxfEJ5IaLERTfLY4Kk= Received: from smtpclient.apple (unknown [209.180.167.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-sasl21.pobox.com (Postfix) with ESMTPSA id 2800F1DAB0; Tue, 21 Nov 2023 13:11:55 -0500 (EST) (envelope-from gak@dancingbear.dev) From: Gary Klimowicz Message-Id: <2B3E59A4-1FA3-4FDC-B508-2925B32B19CC@dancingbear.dev> Content-Type: multipart/alternative; boundary="Apple-Mail=_2F35F9BE-93E3-4604-961D-02981E4DCF38" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: [J3] [SC22WG5.6512] RE: [ukfortran] Fwd: [SC 22 Convenors] JTC 1 plenary wrap-up - Electronic attachments to standard Date: Tue, 21 Nov 2023 10:11:23 -0800 In-Reply-To: Cc: General J3 interest list , WG5 List , Malcolm Cohen To: "Long, Bill F" References: <88db4232-2af2-47a2-9a28-f999095078f3@dmk.com> <20231120210233.6A33E356B79@www.open-std.org> <20231121065421.7C32D356B8E@www.open-std.org> X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Pobox-Relay-ID: 73F7A12C-8899-11EE-AD8B-886C83653EBD-83697616!pb-sasl21.pobox.com Sender: owner-sc22wg5@open-std.org Precedence: bulk --Apple-Mail=_2F35F9BE-93E3-4604-961D-02981E4DCF38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It's about it being in plain text, not in PDF form. As an Annex, they're = difficult to manipulate textually. As plain text, I can image tools we could write for automatically = generating parser definitions (especially for formal definition tools = like SDF or Maude). Identifying changes between version would be much = easier. I also heard from some of the Flang developers that it would have been = helpful to be able to map the constraint numbers and to highlight = textual differences in the constraints between versions of the standard. > On Nov 21, 2023, at 09:54, Long, Bill F wrote: >=20 > Such lists would seem more natural in an Annex as part of the = standard.=20 >=20 >=20 > From: J3 on behalf of Gary = Klimowicz via J3 > Sent: Tuesday, November 21, 2023 11:32 AM > To: General J3 interest list > Cc: Gary Klimowicz ; WG5 List = ; Malcolm Cohen > Subject: Re: [J3] [SC22WG5.6512] RE: [ukfortran] Fwd: [SC 22 = Convenors] JTC 1 plenary wrap-up - Electronic attachments to standard > =20 > I can imagine it would also be helpful to attach as separate text = files a list of the rules and a list of the constraints. >=20 >> On Nov 20, 2023, at 22:47, Malcolm Cohen via J3 = wrote: >>=20 >> It would have been useful many years ago, for the source code of the = ISO_VARYING_STRING module. >> =20 >> Van suggests: >> > Could we publish the "standard" as an abstract on paper, and the = "real" standard as an electronic attachment? >> =20 >> No. The normative text has to be part of the standard. >> =20 >> Cheers, >> --=20 >> ..............Malcolm Cohen, NAG Oxford/Tokyo. >> =20 >> From: Steve Lionel >=20 >> Sent: Tuesday, November 21, 2023 6:03 AM >> To: WG5 List > >> Subject: [ukfortran] [SC22WG5.6510] Fwd: [SC 22 Convenors] JTC 1 = plenary wrap-up - Electronic attachments to standard >> =20 >> Interesting concept - I wonder if there's anything we can do with it. >> -------- Forwarded Message --------=20 >> Subject:=20 >> Re: [SC 22 Convenors] JTC 1 plenary wrap-up >> Date:=20 >> Mon, 20 Nov 2023 12:45:33 -0800 >> From:=20 >> David Keaton >> To:=20 >>=20 >>=20 >> Dear SC 22 Convenors, >>=20 >> There is one item I forgot to mention from last week's JTC 1 plenary = meeting. ISO and IEC have approved the concept of "electronic = attachments" to standards. These have several interesting properties. >>=20 >> * Electronic attachments are distributed together with the standard, = so anyone who buys the standard has the attachments. >>=20 >> * An electronic attachment can contain any kind of data, such as a = machine-readable grammar for a programming language, a sample computer = program, pictures, databases, or even text. Text attachments might = include such things as a list of identifiers, a cross-reference list, or = a change history of the standard. ISO and IEC do not need to know how to = process the attachments; they are only for use by the customers of the = standard. >>=20 >> * Customers are charged by the page of the standard. Electronic = attachments are not counted; they are included for free. Consequently, = some items that might otherwise have resulted in large annexes could = instead be submitted as electronic attachments, giving customers access = to the same data for less money. >>=20 >> Electronic attachments create some pretty exciting possibilities, and = I hope you will keep them in mind during standards development. >>=20 >> David --Apple-Mail=_2F35F9BE-93E3-4604-961D-02981E4DCF38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It's about it = being in plain text, not in PDF form. As an Annex, they're difficult to = manipulate textually.

As plain text, I can image = tools we could write for automatically generating parser definitions = (especially for formal definition tools like SDF or Maude). Identifying = changes between version would be much easier.

I also = heard from some of the Flang developers that it would have been helpful = to be able to map the constraint numbers and to highlight textual = differences in the constraints between versions of the = standard.



On Nov 21, 2023, at 09:54, Long, Bill F = <william.long@hpe.com> wrote:

Such lists would seem = more natural in an Annex as part of the standard. 


From: J3 = <j3-bounces@mailman.j3-fortran.org> on behalf of Gary Klimowicz = via J3 <j3@mailman.j3-fortran.org>
Sent: Tuesday, November 21, 2023 = 11:32 AM
To: General J3 interest list = <j3@mailman.j3-fortran.org>
Cc: Gary Klimowicz = <gak@dancingbear.dev>; WG5 List <sc22wg5@open-std.org>; = Malcolm Cohen <malcolm@nag-j.co.jp>
Subject: Re: [J3] [SC22WG5.6512] RE: = [ukfortran] Fwd: [SC 22 Convenors] JTC 1 plenary wrap-up - Electronic = attachments to standard
 
I can imagine it would also be helpful to attach as = separate text files a list of the rules and a list of the = constraints.

On Nov 20, 2023, at 22:47, Malcolm Cohen via J3 = <j3@mailman.j3-fortran.org> wrote:

It would have = been useful many years ago, for the source code of the = ISO_VARYING_STRING module.
 
Van = suggests:
> Could we publish the "standard" as an = abstract on paper, and the "real" standard as an electronic = attachment?
 
No. The = normative text has to be part of the standard.
 
Cheers,
-- 
..............Malcolm Cohen, NAG Oxford/Tokyo.
 
From: Steve Lionel <steve@stevelionel.com> 
Sent: Tuesday, November 21, = 2023 6:03 AM
To: WG5 List <sc22wg5@open-std.org>
Subject: [ukfortran] = [SC22WG5.6510] Fwd: [SC 22 Convenors] JTC 1 plenary wrap-up - Electronic = attachments to standard
 
Interesting concept - I wonder if there's = anything we can do with it.
-------- Forwarded = Message -------- 
Subject: 
Re: [SC 22 Convenors] JTC 1 plenary = wrap-up
Date: 
Mon, 20 Nov 2023 12:45:33 = -0800
From: 
David Keaton <dmk@dmk.com>
To: 


Dear SC = 22 Convenors,

There is one item I forgot to mention from last = week's JTC 1 plenary meeting. ISO and IEC have approved the concept of = "electronic attachments" to standards. These have several interesting = properties.

* Electronic attachments are distributed together = with the standard, so anyone who buys the standard has the = attachments.

* An electronic attachment can contain any kind of = data, such as a machine-readable grammar for a programming language, a = sample computer program, pictures, databases, or even text. Text = attachments might include such things as a list of identifiers, a = cross-reference list, or a change history of the standard. ISO and IEC = do not need to know how to process the attachments; they are only for = use by the customers of the standard.

* Customers are charged by = the page of the standard. Electronic attachments are not counted; they = are included for free. Consequently, some items that might otherwise = have resulted in large annexes could instead be submitted as electronic = attachments, giving customers access to the same data for less = money.

Electronic attachments create some pretty exciting = possibilities, and I hope you will keep them in mind during standards = development.

David
=

= --Apple-Mail=_2F35F9BE-93E3-4604-961D-02981E4DCF38--