emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Re: Thoughts on the standardization of Org
@ 2020-11-01 13:34 Gustav Wikström
  0 siblings, 0 replies; 71+ messages in thread
From: Gustav Wikström @ 2020-11-01 13:34 UTC (permalink / raw)
  To: Asa Zeren, emacs-orgmode@gnu.org

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


^ permalink raw reply	[flat|nested] 71+ messages in thread
* Re: Thoughts on the standardization of Org
@ 2020-11-03 22:30 Asa Zeren
  0 siblings, 0 replies; 71+ messages in thread
From: Asa Zeren @ 2020-11-03 22:30 UTC (permalink / raw)
  To: emacs-orgmode

I have collected below some quotations to try to represent the general
sentiments expressed so far in the conversation, upon which I would like to
express some thoughts. Most of these have been repeated several times in spirit,
so they are not just the opinions of the listed authors.

Daniele Nicolodi <daniele@grinta.net> said:
> I don't think it is reasonable to expect much of org-mode being implemented in
> another environment, because that quickly becomes a task as complex as
> implementing Emacs. For example, Org has org-tables, and the formula syntax
> allows for Emacs Calc expressions or Elisp functions to be called: should an
> hypothetical implementation of Org allow the same formulas to be executed?
> Wouldn't that mean that this implementation needs to re-implement a good
> fraction of Emacs (or use Emacs itself for interpreting the formulas?
>
> Maybe the standardization should cover only the "static" parts of Org (IE no
> table formulas, no babel, no agenda, no exporters, etc). However, in this
> case, what is left is little more of a markup language with an editor that
> allows sections folding. You can have this on top of pretty much any markup
> language using Emacs' outline-minor-mode.

Daniele Nicolodi <daniele@grinta.net> said:
> one of the advantages of Org is that, being implemented in Emacs, it has
> infinite potential for customization, thus we would need to agree about what
> org mode is before standardizing it: my Org is not your org, and, thank to the
> features offered be the Emacs environment, I use different flavors of Org in
> different buffers.

I 100% agree that much of the power of org mode comes from the infinite
customization. However, I do not agree that this fact makes standardization
impossible (see below). Additionally, Emacs is not the only customizable tool,
though it is a very good one. The org standard would have to be flexible to
accommodate that "my org is not your org," but this is not impossible.

Ken Mankoff <mankoff@gmail.com> said:
> Therefore, if other tools have the ability to do *something* with an Org file
> (display most of it well enough, allow editing without breaking things, maybe
> implementing a simple Babel interpreter for a few popular languages,
> whatever), this would be A Good Thing.

TEC <tecosaur@gmail.com> said:
> I also think it's to our benefit that non-Emacsers become more comfortable
> with seeing an org file --- as I see it that improves our chances that we can
> directly share Org files with them, which they might be comfortable editing
> and sending back for example, or that a generic tool might think to support
> Org files.

These points are especially important, and while a standard is not the only way
to progress these goals, it is a good step. Also, re the MIME type discussion,
while there was a long list of steps that need to occur for a MIME registration
to be useful, I would like to point out that a standard is the first step
towards that goal, and even though there are more steps, many of them difficult,
that does not mean that we should not make progress.

Greg Minshall <minshall@umich.edu>
> 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.

This is a good precedent for how I would like to standardize org. First,
standardize general structure, without the specifics. Then, as ideas around a
particular feature stabilize, they can be separately standardized, and
incrementally adopted. (Though likely many major implementations (aka Emacs)
would have already implemented it, even though it is non standard.)

For more details on how I think this should be accomplished, see my original
post, and also this reply for clarification:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg00009.html

Ken Mankoff <mankoff@gmail.com> said:
> The conversation should move from "it can't be done" or "it isn't helpful"
> (why so much negativity on this thread?) to
>
> + What parts can be standardized and re-implemented outside of Emacs.
> + How do we define graceful failure for the other parts.
> + How do we support 3rd-party implementation in a way that benefits all of us.

This post I also find especially important. There seem to be the ideas that (a)
an incomplete implementation is not useful and (b) a standard would necessarily
either require another implementation to implement all of Emacs or would
eliminate the customizability of org.

Thanks,
Asa


^ permalink raw reply	[flat|nested] 71+ messages in thread
* Re: Thoughts on the standardization of Org
@ 2020-11-01 18:39 Asa Zeren
  0 siblings, 0 replies; 71+ messages in thread
From: Asa Zeren @ 2020-11-01 18:39 UTC (permalink / raw)
  To: emacs-orgmode

Hi all,

Thank you for your comments on my post "Thoughts on the Standardization of Org."
I appreciate all the feedback you have given me, I feel that, based off of the
responses, there have been a number of miscommunications as to my intention.

First, I did not mean the post to be primarily an argument for whether/when org
should be standardized, but rather a discussion on how a standard should be
structured. I realize now that including my position on whether org should be
standardized in the preamble was a mistake. Also, I want to note that I was not
intending to discuss by whom the standard should be governed. (Though I do
believe it should be by the org community, not an external standards body.)

Second, there is the matter of principle and practice. I am not arguing for the
org community to direct volunteer effort to a second editing environment, as
some are concerned. I am also personally not planning on creating one. However,
I want to make sure that standardization effort does not prevent another
first-class editing environment from being created, should there at some point
in the future emerge a group of people motivated to do that. In summary, I think
that it is important to think about the Emacs implementation as one of many /in
principle/, even though it is the sole implementation /in practice/, and may
remain so.

I hope we can have a productive discussion on how an org standard should be
structured, separate from, though perhaps in addition to, the discussion of
whether org should be standardized.

Thanks,
Asa


^ permalink raw reply	[flat|nested] 71+ messages in thread
* Thoughts on the standardization of Org
@ 2020-11-01  0:22 Asa Zeren
  2020-11-01  0:40 ` Dr. Arne Babenhauserheide
                   ` (6 more replies)
  0 siblings, 7 replies; 71+ messages in thread
From: Asa Zeren @ 2020-11-01  0:22 UTC (permalink / raw)
  To: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 71+ messages in thread

end of thread, other threads:[~2020-11-27 17:25 UTC | newest]

Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-01 13:34 Thoughts on the standardization of Org Gustav Wikström
  -- strict thread matches above, loose matches on Subject: below --
2020-11-03 22:30 Asa Zeren
2020-11-01 18:39 Asa Zeren
2020-11-01  0:22 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
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-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

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).