[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the standardization of Org
From: |
Gustav Wikström |
Subject: |
Re: Thoughts on the standardization of Org |
Date: |
Sun, 1 Nov 2020 13:34:55 +0000 |
Hi,
I agree with your sentiment Asa. It would indeed be good to "standardize" Org.
It's worth spending a few words here reasoning about what this standardization
would mean. The text below are not specifically to you, Asa. But to the list.
As food for thought on this topic. FWIW.
It's easy to be hesitant to standardization, thinking it will slow down and
limit development. Personally I don't think Org mode is at risk of that. The
issues come first with coordination between multiple parties. Especially if the
visions, goals and perspectives of the parties differ. For Org mode this
coordination should not be an issue, since no one as of now could dispute that
Emacs Org mode implementation is the standard implementation. Few would also
dispute which party has the leading role in defining the standard. (I.e. this
community, with the maintainers as the "signing" bodies, define the standard.
And it can be done either in the manual or in worg).
Issues with a standard hindering evolution of Emacs Org mode can be dealt with
in the same way as the evolution of Org mode itself is handled. By versioning.
Right now the Org mode version effectively declares what the DOM and syntax is.
If we can extract that information from the source code. And assign a version
to the DOM and syntax so they can be managed separate from the Emacs
implementation, it's quite easy to evolve them as well. Although I think the
syntax will evolve much less than the tool itself, since much of the changes
aren't about changing the syntax but rather about changing the way Emacs
augments and works with that syntax!
What it really boils down to, I think, is that there is a benefit of a clear
document describing what an org mode document can consist of (DOM in your
terminology I suppose?) and what the textual representation of that is (the
syntax). Put a version number on that/those things that can be incremented as
the community see fit. And it's done. Standard is defined. No third party
should need to sign it. It would be the "Emacs Org mode" community
standardization of the Org mode object model and textual syntax and document
format. And that in itself should be more than enough to get the ".org" file
extension globally approved. And help parser developers and other tool
developers to support the format. AND help further develop Emacs
implementation. Discussions regarding composing these documents are already
started in the MIME-type threads. In my humble opinion there is not much else
needed to get this "standardization" done.
Nicolas has started the journey in an excellent way with the Org element
documentation and source code library in my opinion. Hats off to him! Anyone
willing of following in his footstep gets another hat off. I'm sure it will be
of great benefit to all Org mode users out there!
Kind regards
Gustav
> -----Ursprungligt meddelande-----
> Från: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> För Asa
> Zeren
> Skickat: den 1 november 2020 01:22
> Till: emacs-orgmode@gnu.org
> Ämne: Thoughts on the standardization of Org
>
> 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
- Re: Thoughts on the standardization of Org, (continued)
- Re: Thoughts on the standardization of Org, Tom Gillespie, 2020/11/01
- Re: Thoughts on the standardization of Org, Dr. Arne Babenhauserheide, 2020/11/01
- Re: Thoughts on the standardization of Org, Asa Zeren, 2020/11/01
- Re: Thoughts on the standardization of Org, Dr. Arne Babenhauserheide, 2020/11/01
- Re: Thoughts on the standardization of Org, TEC, 2020/11/01
- Re: Thoughts on the standardization of Org, Asa Zeren, 2020/11/01
Re: Thoughts on the standardization of Org, TEC, 2020/11/01
Re: Thoughts on the standardization of Org, Tim Cross, 2020/11/01
Re: Thoughts on the standardization of Org,
Gustav Wikström <=
Re: Thoughts on the standardization of Org, Russell Adams, 2020/11/01
- Re: Thoughts on the standardization of Org, Daniele Nicolodi, 2020/11/01
- Re: Thoughts on the standardization of Org, Dr. Arne Babenhauserheide, 2020/11/01
- Re: Thoughts on the standardization of Org, Daniele Nicolodi, 2020/11/02
- Re: Thoughts on the standardization of Org, TEC, 2020/11/02
- Re: Thoughts on the standardization of Org, Daniele Nicolodi, 2020/11/02
- Re: Thoughts on the standardization of Org, TEC, 2020/11/02
- Re: Thoughts on the standardization of Org, Jean Louis, 2020/11/07
- Re: Thoughts on the standardization of Org, Maxim Nikulin, 2020/11/09
- Re: Thoughts on the standardization of Org, Daniele Nicolodi, 2020/11/09