From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Tue Nov 21 18:41:52 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 B516D356B04; Tue, 21 Nov 2023 18:41:52 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 545 seconds by postgrey-1.34 at www5.open-std.org; Tue, 21 Nov 2023 18:41:52 CET Received: from sasl.smtp.pobox.com (pb-sasl20.pobox.com [173.228.157.48]) by www.open-std.org (Postfix) with ESMTP id 27C0E356A61 for ; Tue, 21 Nov 2023 18:41:51 +0100 (CET) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl20.pobox.com (Postfix) with ESMTP id 507302ED46; Tue, 21 Nov 2023 12:32:44 -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=CsXvksUy2v66WBfYB4wtN3JCKzd050L0Jr f0G7FnGB0=; b=khbWo9gvg5Z2GgDuSQt7zNdoaXEI11XF4/V0yihkWifUBNhOVA 78hMYj9TnpbWMzOMhDr7zoPhOxA4M5Hqsy/KqRdfrEnp4sRD9aESuFcg9vTukfQ0 qDG40KU4bNXvDYomdIojyRHn+oAqN5e9yT35ksIx1sLu5C8ipkxGdsU64= Received: from pb-sasl20.sea.icgroup.com (unknown [127.0.0.1]) by pb-sasl20.pobox.com (Postfix) with ESMTP id 3CCE02ED45; Tue, 21 Nov 2023 12:32:44 -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=CsXvksUy2v66WBfYB4wtN3JCKzd050L0Jrf0G7FnGB0=; b=HBizfTunORoFAXWHhXvgGY9WbKAf1Zv3xBKI7NVAjXN/jRv38iyfWZMN9BgiYdIqS/RmbPZggICmFPCC9oNHM1FbolsfC8FZ1BxumgcBzrm86Kv8kyYRZWXay1DDe5Kx4nlt0AApbrrPnMsbIfe7Vozzo1uXWNUDuwGRwKXTzTA= 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-sasl20.pobox.com (Postfix) with ESMTPSA id DB8CC2ED44; Tue, 21 Nov 2023 12:32:40 -0500 (EST) (envelope-from gak@dancingbear.dev) From: Gary Klimowicz Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FF3E1DFE-BD9B-438C-9D06-56BBC32A2B6D" 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 09:32:09 -0800 In-Reply-To: <20231121065421.7C32D356B8E@www.open-std.org> Cc: WG5 List , Malcolm Cohen To: General J3 interest list 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: F8B60BB6-8893-11EE-BD0E-9D03A8A19EB0-83697616!pb-sasl20.pobox.com Sender: owner-sc22wg5@open-std.org Precedence: bulk --Apple-Mail=_FF3E1DFE-BD9B-438C-9D06-56BBC32A2B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = 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=_FF3E1DFE-BD9B-438C-9D06-56BBC32A2B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 -------- 
Re: [SC 22 Convenors] JTC 1 plenary = wrap-up
Mon, 20 Nov 2023 12:45:33 = -0800
David Keaton <dmk@dmk.com>
Subject: 
Date: 
From: 
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=_FF3E1DFE-BD9B-438C-9D06-56BBC32A2B6D--