Tim Cross <theophil...@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
