From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QunnHbFWnl8tFwAA0tVLHw (envelope-from ) for ; Sun, 01 Nov 2020 06:33:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id mMGMGbFWnl8IOAAAbx9fmQ (envelope-from ) for ; Sun, 01 Nov 2020 06:33:21 +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 D211A9403EB for ; Sun, 1 Nov 2020 06:33:20 +0000 (UTC) Received: from localhost ([::1]:39710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZ6vX-0007SC-BT for larch@yhetil.org; Sun, 01 Nov 2020 01:33:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59070) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZ6v5-0007Rn-NZ for emacs-orgmode@gnu.org; Sun, 01 Nov 2020 01:32:52 -0500 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:50212) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZ6v3-00069u-PG for emacs-orgmode@gnu.org; Sun, 01 Nov 2020 01:32:51 -0500 Received: by mail-pj1-x1030.google.com with SMTP id ie6so997931pjb.0 for ; Sat, 31 Oct 2020 23:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=A2kLJH/0lxmhUlHDGLU0ewMQmrwm7920iQJPFjKGRNU=; b=VWdeNV4c4Hwc8WZPtqXmsfK2vehTrfQ1BBm9+oPg6MuWdauQ1wrZWxZq2/Rcpei4hj WHGTbnD+ZKZ2dpqlzjHuanzINkJx2T6xVLUPuYf2g8rpWVJMrr3L7K9cBpAoA/lniNDE kgXEOokYOqMEJQceGgwTmGVGjDjWcdZLSLcrypY4H3zEIpFde592BLUGXWXO2vqZ3cVV zTeJNdrYdE/6DITkN3ssMt2qbOA7CA5EJqIZQu0A4v44tR0OGLD5HBP04NYA3GjdxEjZ Ms5cPPZfui2y54u4OS8DGhPthvFkJYsKMIFoKuT6cs0TSLsVL8blmL1mXxXmGItdNhFB li4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=A2kLJH/0lxmhUlHDGLU0ewMQmrwm7920iQJPFjKGRNU=; b=hTFt9c8gvaxgd/e4r67uo4FIXcqu3IDbQPWfMv18M7E79aDEciR4jvpVfXxY80g6ZY NpkebIoPukMuommWSoyhEj0Lykh/4kzuI428utVcz6dFSVQwlXybMvI8AgymnEJTfZNS /Dp8N++CnWzirjjOi0jeVN5erIIf9KUl7is51EK5Q9nm8LxGBvURZWIh/XVqh/e6ByMq LOW3hUPRTW8wWNOFdyVUvx1HOwYhi0ryBsSwl5gmmcLEMN4KUeR5a0bw85B1+z/54Msk IxVU5CCZD6h77A0erhg/WMVbM/+2Ubizug+UQUHnimgdym/jGFZPbi1lv0WuqUjboZX1 9hxQ== X-Gm-Message-State: AOAM531UKsb4Ob/pCoY8dP+9yPUYxFw1hovI0thfVnjnHNpGvXGxbRf+ 1LM4BXK/ir8VW9+kD+3SOxQHzq+yshU= X-Google-Smtp-Source: ABdhPJw8h5GcQQ014ScZMeH3JHrYDuad+IaIVy5bNvCg9wNVVxRN65/3PVBYYspSBWjwI98C4qMoAA== X-Received: by 2002:a17:902:b903:b029:d6:631e:c99e with SMTP id bf3-20020a170902b903b02900d6631ec99emr16635460plb.14.1604212367476; Sat, 31 Oct 2020 23:32:47 -0700 (PDT) Received: from localhost (180-150-91-8.b4965b.per.nbn.aussiebb.net. [180.150.91.8]) by smtp.gmail.com with ESMTPSA id 145sm9429560pga.46.2020.10.31.23.32.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Oct 2020 23:32:46 -0700 (PDT) References: User-agent: mu4e 1.4.13; emacs 27.1 From: TEC To: emacs-orgmode@gnu.org Subject: Re: Thoughts on the standardization of Org Date: Sun, 01 Nov 2020 14:24:18 +0800 In-reply-to: Message-ID: <877dr57fjo.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=tecosaur@gmail.com; helo=mail-pj1-x1030.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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: , 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=pass header.d=gmail.com header.s=20161025 header.b=VWdeNV4c; dmarc=pass (policy=none) header.from=gmail.com; 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: -1.71 X-TUID: 8QmKJ6GWZ1/4 Hi all, Following what I've read on the list I've developed thoughts on what the best approach might be. My current thinking is that it may be possible to have Org registered as a standard in such a way that it does not constrain our development efforts. How? We forgo locking down the precise format and behaviour of every Org element. Instead we only submit something like https://orgmode.org/worg/dev/org-syntax.html which /just/ describes the overall syntax. I don't imagine that 'locking' ourself into the current syntax described in https://orgmode.org/worg/dev/org-syntax.html would actually hurt development, but might be enough for a MIME type etc. Then perhaps just say for description of how specific/special instances of those structural elements are supposed to work see the reference implementation. Just a few thoughts from me. All the best, Timothy. Asa Zeren writes: > Hi, > > Even though I am new to the org-mode community, I would like to > share > some thoughts on the specification of org-mode, especially since > I > have seen some recent discussion of it in relation to > registering org > as a MIME type. > > First, I would like to repeat the importance of developing > standards > for org-mode. If we want to expand the influence of org, tooling > must > expand beyond Emacs. While Emacs is an amazing tool, (a) we > cannot > convince the entire world to use Emacs and (b) org-mode should > be > integrated into tooling unrelated to text editing, and is > outside of > the Emacs-Lisp environment. Without additional org > implementations, > this is impossible. If org catches on before it is standardized, > we > end up in the situation of Markdown, with many competing > standards and > non-standards. Hence, standardization is essential. > > Standardizing org is much harder than standardizing something > like > Markdown, but I think by breaking it down as follows will > maximize the > portability of org while not compromising on development of org. > > I see three areas of standardization, which I think should be > standardized separately: > - Org DOM > - Org Syntax > - Org Standard Environments > > Before we get to that, a brief note on /how/ I think that org > should > be specified. I think that org should be specified in terms of > an > /environment/ that defines the properties, etc. that can be used > in a > document. For instance, the org standard would say something to > the > effect of "An environment may specify block bounding keywords > that may > be used like #+\n...#+. and the environment would > specify > "begin_src and end_src are a pair of block bounding keyword that > indicates a source code block." This is for two reasons. First, > this > allows for development of org tool features independent of the > standard. Second, this separates the individual features of org > mode > from the overall structure. > > Org DOM: > The first thing to specify is the org DOM. (Maybe a different > name > should be used to avoid confusion with the HTML DOM) This is the > structure of an org-mode document, without the textual > representation. Many org-related tools operate on org documents > without needing to use the textual representation. Specifying > the DOM > separately would (a) create a separation of concerns and (b) > allow for > better libraries built around org mode. > > Org Syntax: > This would be specifying the mapping between the DOM and the > textual > representation, specified in terms of an environment. > > Org Standard Environments: > This is how I would specify elements such as > #+begin_src..#+end_src > would be specified, as standardized elements of the environment. > This > would be structured as a number of individual standard > environments, > such as "Source Blocks" or "Standard Header Properties" > (specifying > #+title, #+author, etc.) > > I would appreciate thoughts on these ideas about how to develop > and > org specification. > > Thanks for reading, > Asa Zeren