emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on the standardization of Org


From: Pankaj Jangid
Subject: Re: Thoughts on the standardization of Org
Date: Sun, 01 Nov 2020 09:09:24 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin)

Tim Cross <theophilusx@gmail.com> writes:

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

Not only that. This will really slowdown the evolution of org-mode if
the standardization is outside the control of Emacs Developers.

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

I am not only skeptical, I totally believe that this sort of
standardization where some other party is giving org-mode a certificate,
will be harmful for the development of org-mode.

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

And this should be the only source of truth. If MIME type registration
changes this then better to avoid that.

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

Agree. And again... the standard place should be Worg only.

-- Pankaj



reply via email to

[Prev in Thread] Current Thread [Next in Thread]