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 +O2HLWQdnl/VGwAA0tVLHw (envelope-from ) for ; Sun, 01 Nov 2020 02:28:52 +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 WJRYKWQdnl/NFgAAbx9fmQ (envelope-from ) for ; Sun, 01 Nov 2020 02:28:52 +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 078169403CC for ; Sun, 1 Nov 2020 02:28:52 +0000 (UTC) Received: from localhost ([::1]:48554 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZ36v-0004NC-Nr for larch@yhetil.org; Sat, 31 Oct 2020 22:28:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZ36a-0004N5-1Y for emacs-orgmode@gnu.org; Sat, 31 Oct 2020 22:28:28 -0400 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]:35143) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZ36X-0006vn-UY for emacs-orgmode@gnu.org; Sat, 31 Oct 2020 22:28:27 -0400 Received: by mail-pf1-x42c.google.com with SMTP id b3so8217743pfo.2 for ; Sat, 31 Oct 2020 19:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version; bh=uWX+aGF0nkQ4vGn6b4LVVbvi9v33R4m7Lzm6lfIY7Ws=; b=t3ydNWegsDaZ+zIS0N0IkbpmEIGs98JEPhoSVAsBU5ZnUwmW2KbYyjgbRO7omCCVG6 e3i3Y6n9bmLH3RZvvK5qV0JNx6PtUiO2pv89uaVDXJ13BNjLHmFYkawnp7ksL6e/UOtF XKUSZf0WsBoEJe98T27g4wrDq1JbFSsoOTj5sj5hbYFfdDZHA1gxYN6jLN59CHxxJcPk C8t98gdgbo/W3xmbOqVOqzfKZ/KDuPrAkESIqO4CYT1m/aGdE1U1AxF4jcTjurdi4kce Yut41ZGs9yCUnpriJ+8Lcr/anTNMfgDjkFcMrSl9wAtm5uiKfsf+E8UcjxOUdPR31/un 4vDg== 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 :in-reply-to:message-id:date:mime-version; bh=uWX+aGF0nkQ4vGn6b4LVVbvi9v33R4m7Lzm6lfIY7Ws=; b=hpM+4sxhoMZa7hDXHQi8eNZkow1Oi/bEy/RF6eO/FP8IxaW0RISIgFngDKH+175oe7 HyRty5KOx5Meb0pXd8fw8YKj9GI/3iwQe0DeomnxujZi1IsNXY6QKOrk88EAQOutOEhr w6l7rqizVe0YCTOYp3Ae2ZWyulJRAvGT2mqPOAzFS3RUhQLzkOmFrfp2366FES3VkAG1 W83jG+VbDHcOdWs+48u/xgmOPXsCrMsUAQiw5bxJbylDuz9f0zKgHisG0eVFvzfkku5C ai03RPezivmGHRGq5pMGCJq8QGEH4F4WFG6Zx6+paVBE4mfIHkb8A69KPXR/xOa9vKli XlXg== X-Gm-Message-State: AOAM533nUXZh79a7M7N+aueW+tNDwHpb5CXSD93zBv9goRjaPzM9YMvo sUSFNavQSV1qZxwAOyktBaPzbuZJnZL0IA== X-Google-Smtp-Source: ABdhPJywmbQcHi75kWITctYezYjgf6wRj6ia3+pczwwPHtMJovM9PWErvRYcy4kS2xKggqeqC+HFDQ== X-Received: by 2002:a65:4cc9:: with SMTP id n9mr8448607pgt.236.1604197703813; Sat, 31 Oct 2020 19:28:23 -0700 (PDT) Received: from tim-desktop (106-69-155-166.dyn.iinet.net.au. [106.69.155.166]) by smtp.gmail.com with ESMTPSA id e23sm9567770pfi.191.2020.10.31.19.28.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Oct 2020 19:28:22 -0700 (PDT) References: User-agent: mu4e 1.5.6; emacs 27.1.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Thoughts on the standardization of Org In-reply-to: Message-ID: <878sbln73x.fsf@gmail.com> Date: Sun, 01 Nov 2020 13:28:18 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42c; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42c.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=t3ydNWeg; 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: sRfa3jidnQ+H I think there are a couple of important points to consider in discussions of this type. I should state up-front, I am somewhat sceptical regarding an org-mode which is separate or independent of Emacs. Much of what makes org-mode so powerful and useful is due to features of Emacs. While most, if not all, of these features could be implemented in other solutions, the amount of work and level of maintenance should not be under-estimated. While standards and formal standardisation of something can be important, it is often a dual edge sword. Over the last 30+ years involved in technology, I have seen many good ideas come undone as the result of a standardisation effort. consider for example, the results of the lisp standardisation that resulted in common Lisp, what happened with CORBA, xml-rpc and the move to REST based APIs. XHTML and the breakdown of standardisation processes within the W3C and the development of HTML5. Sometimes, we can emerge from a standardisation process with a clearer, consistent standard that is easy to implement and use. Other times, we can emerge with a complex, difficult to implement and confusing standard which can kill or stifle further development. The trick with standardisation seem to be getting the balance right between clarity and complexity and focusing on the key requirements, avoiding the trap of trying to cover everything. One of the things I like a lot about org-mode is that it is not terribly prescriptive. It provides a collection of features and functions which you are able to assemble according to your own needs and preferences. While I think it is important to have a clear idea of basic syntax for each of these elements and how they relate to each other, I'm less convinced we would want to prescribe an overly formal specification for how an org document should be structured i.e. the org DOM idea. The existing draft syntax document is probably sufficiently prescriptive here already. The four areas which I think would provide the greatest benefit would be to - Finalise the draft org syntax document on Worg, possibly adding it to the manual once complete. A considerable amount of work has already been put into this document and I think it is a good start. - Define a specification for a property API which compliant org-mode implementation should support. This could be based on the existing ELisp mapping API. - Define a specification for an element mapping API which compliant org-mode implementation should support. Again, this could be based on the existing ELisp element mapping API. - Define a set of org reference documents. These would be documents that all compliant parsers should be able to process successfully. It might also be worthwhile including some documents with common errors which parses should be able to handle and recover from in a graceful manner. Those developing external tools can then use these documents as a guide and for testing their implementations. Tim 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 -- Tim Cross