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 <asaize...@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
