From: TEC <tecosaur@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Thoughts on the standardization of Org
Date: Sun, 01 Nov 2020 14:24:18 +0800 [thread overview]
Message-ID: <877dr57fjo.fsf@gmail.com> (raw)
In-Reply-To: <CANKzsSBja5GNHWu0VEvH9dSu_vWFhiLyoebTT3GdT_Jc4gxKaw@mail.gmail.com>
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 <asaizeren@gmail.com> 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 #+<kwd_0>\n...#+<kwd_1>. 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
next prev parent reply other threads:[~2020-11-01 6:33 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-01 0:22 Thoughts on the standardization of Org Asa Zeren
2020-11-01 0:40 ` Dr. Arne Babenhauserheide
2020-11-01 3:08 ` Asa Zeren
2020-11-01 4:23 ` Pankaj Jangid
2020-11-01 7:54 ` Tim Cross
2020-11-01 2:28 ` Tim Cross
2020-11-01 3:39 ` Pankaj Jangid
2020-11-02 12:39 ` Eric S Fraga
2020-11-02 14:22 ` Greg Minshall
2020-11-02 14:56 ` Eric S Fraga
2020-11-02 15:23 ` Russell Adams
2020-11-02 15:31 ` TEC
2020-11-02 15:48 ` Eric S Fraga
2020-11-02 16:27 ` Carsten Dominik
2020-11-02 22:05 ` Tim Cross
2020-11-03 3:29 ` Greg Minshall
2020-11-01 5:20 ` Tom Gillespie
2020-11-01 10:25 ` Dr. Arne Babenhauserheide
2020-11-01 10:28 ` TEC
2020-11-01 18:02 ` Jack Kamm
2020-11-01 16:03 ` Asa Zeren
2020-11-01 17:27 ` Dr. Arne Babenhauserheide
2020-11-01 17:29 ` TEC
2020-11-01 18:43 ` Asa Zeren
2020-11-01 6:24 ` TEC [this message]
2020-11-01 16:13 ` Russell Adams
2020-11-01 19:46 ` Daniele Nicolodi
2020-11-01 23:10 ` Dr. Arne Babenhauserheide
2020-11-02 8:37 ` Daniele Nicolodi
2020-11-02 9:02 ` TEC
2020-11-02 11:04 ` Daniele Nicolodi
2020-11-02 13:43 ` TEC
2020-11-07 21:20 ` Jean Louis
2020-11-09 14:04 ` Maxim Nikulin
2020-11-09 15:57 ` Daniele Nicolodi
2020-11-09 15:59 ` Jean Louis
2020-11-10 16:19 ` Maxim Nikulin
2020-11-10 20:22 ` Jean Louis
2020-11-10 23:08 ` Tom Gillespie
2020-11-11 0:00 ` Tim Cross
2020-11-09 21:46 ` Tim Cross
2020-11-09 22:45 ` Emails are not safe - " Jean Louis
2020-11-10 4:13 ` Greg Minshall
2020-11-10 4:49 ` Tim Cross
2020-11-10 7:12 ` Greg Minshall
2020-11-10 16:29 ` Maxim Nikulin
2020-11-10 20:35 ` Jean Louis
2020-11-10 22:30 ` Tim Cross
2020-11-11 5:03 ` Jean Louis
2020-11-11 6:40 ` Tim Cross
2020-11-27 16:49 ` Maxim Nikulin
2020-11-27 17:16 ` Jean Louis
2020-11-11 17:10 ` Maxim Nikulin
2020-11-11 17:34 ` Jean Louis
2020-11-12 3:39 ` Greg Minshall
2020-11-11 3:49 ` Greg Minshall
2020-11-02 9:53 ` Dr. Arne Babenhauserheide
2020-11-02 1:17 ` Ken Mankoff
2020-11-02 8:12 ` Russell Adams
2020-11-02 9:57 ` Dr. Arne Babenhauserheide
2020-11-03 8:24 ` David Rogers
2020-11-03 12:14 ` Ken Mankoff
2020-11-03 12:27 ` Russell Adams
2020-11-03 13:00 ` Eric S Fraga
2020-11-03 13:31 ` Ken Mankoff
2020-11-03 15:03 ` Eric S Fraga
2020-11-03 20:27 ` TEC
2020-11-03 14:38 ` Devin Prater
2020-11-03 22:03 ` David Rogers
-- strict thread matches above, loose matches on Subject: below --
2020-11-01 13:34 Gustav Wikström
2020-11-01 18:39 Asa Zeren
2020-11-03 22:30 Asa Zeren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877dr57fjo.fsf@gmail.com \
--to=tecosaur@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).