From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id YI9TDc/OoF9tCwAA0tVLHw (envelope-from ) for ; Tue, 03 Nov 2020 03:30:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id wLkOCc/OoF8lKQAAB5/wlQ (envelope-from ) for ; Tue, 03 Nov 2020 03:30:23 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 992C89402A9 for ; Tue, 3 Nov 2020 03:30:22 +0000 (UTC) Received: from localhost ([::1]:49744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZn1Y-00036I-Mj for larch@yhetil.org; Mon, 02 Nov 2020 22:30:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZn11-000365-Ae for emacs-orgmode@gnu.org; Mon, 02 Nov 2020 22:29:47 -0500 Received: from hiwela.pair.com ([209.68.5.201]:11279) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZn0z-0004KH-FR for emacs-orgmode@gnu.org; Mon, 02 Nov 2020 22:29:46 -0500 Received: from hiwela.pair.com (localhost [127.0.0.1]) by hiwela.pair.com (Postfix) with ESMTP id A90BD980545; Mon, 2 Nov 2020 22:29:43 -0500 (EST) Received: from minshall-entroware-apollo.cliq.com (unknown [188.58.100.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hiwela.pair.com (Postfix) with ESMTPSA id 7304A8F0850; Mon, 2 Nov 2020 22:29:43 -0500 (EST) Received: from apollo2.minshall.org (localhost [IPv6:::1]) by minshall-entroware-apollo.cliq.com (Postfix) with ESMTP id CFC4460882; Tue, 3 Nov 2020 06:29:41 +0300 (+03) From: Greg Minshall To: Eric S Fraga Subject: Re: Thoughts on the standardization of Org In-reply-to: Your message of "Mon, 02 Nov 2020 14:56:58 +0000." <87mtzz958l.fsf@ucl.ac.uk> X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 27.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1260884.1604374181.1@apollo2.minshall.org> Date: Tue, 03 Nov 2020 06:29:41 +0300 Message-ID: <1260885.1604374181@apollo2.minshall.org> Received-SPF: softfail client-ip=209.68.5.201; envelope-from=minshall@umich.edu; helo=hiwela.pair.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/02 22:29:43 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=umich.edu (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.91 X-TUID: kd0cB1/O+hva Eric, > For instance, in my recent org documents, I have added a #+calc: keyword > which I use for embedded calc lines. This allows me to have a clearly > labelled line that Calc will recognise and that I can process using a > filter before export while also ensuring that other tools, e.g. ones > which will ignore lines starting with #, do not fail. If the standard > did not allow for arbitrary keywords, would this limit my use? perhaps the standard for e-mail headers (originally, RFC822) might be a useful way of thinking about this issue. it standardizes what it standardizes, and then says, "and, by the way, you can put in almost anything else [X-Mailer, ...], but you can't count on any other node understanding it". over time, new things are standardized (and, so, moved to, e.g., Mailer, and other things aren't. it seems to me this has worked fairly well, and partly this works because of the late Jon Postel's admonition for designing internet protocols: be conservative in what you send, and liberal in what you accept. [1] cheers, Greg [1] i.e., be extremely picky about sticking exactly to the letter of the standard in generating, e.g., documents, but allow for some sloppiness in the format of incoming documents.