Re: It's a Markdown processor, right?

[Andy Lee]

On Sep 7, 2014, at 1:53 PM, Aristotle Pagaltzis  wrote:
> I would argue that the only sufficiently generic term that will apply to
> software in all of these cases is, in fact, “processor”.

How about "Markdown engine"?

--Andy

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: It's a Markdown processor, right?

[Aristotle Pagaltzis]

* Waylan Limberg  [2014-09-08 03:55]:
> How about some of the verbs used by libraries as a method on a class
> instance: "render" or "convert". Of course we want the nouns:
> "renderer" or "converter". They are very similar to "translator", but
> unlike translator are actually used by the existing implementations.

That would exclude parsers, indexers, etc. whose output is not another
form of the document.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: It's a Markdown processor, right?

[Waylan Limberg]

How about some of the verbs used by libraries as a method on a class instance: 
"render" or "convert". Of course we want the nouns: "renderer" or "converter". 
They are very similar to "translator", but unlike translator are actually used 
by the existing implementations.

Waylan Limberg

> On Sep 7, 2014, at 2:31 PM, Andrei Fangli  wrote:
> 
> Sean wrote:
> > I am trying to use uniform terms. An implementation that converts
> Markdown content to another format--most typically HTML--is called...a
> Markdown processor, right?
> 
> I was focusing on naming the software that takes text in format A and outputs 
> it in format B (yep, just that use case). The XML specifications define that 
> a XML Processor is something that recognizes the structure of a XML Document, 
> validates it and offers access to its content (e.g.: by tree traversal since 
> XML is hierarchical in nature). A software that simply translates from format 
> A to B only recognizes, validates the structure of the text in format A and 
> outputs the content in format B. If we were to apply an analogous definition 
> for a Markdown Processor then the access to content is lost because the 
> initial document as a whole is outputted in format B without having the 
> chance to peak at its content. In that case we cannot name that software a 
> processor, it may use one internally to get the job done.
> 
> In the case of a software that allows visualisation of Markdown documents 
> prior to translation/export, eventually allowing editing, indexing, word 
> count, page count etc., I agree, that no longer can be called a translator 
> because it does much more. That software falls well in the terms of a word 
> processor (specialized for Markdown in this case) as pointed out, however I’m 
> not sure that’s what Sean was asking.
> 
> This discussion is turning out quite interesting as parsers require a grammar 
> in a formal language (e.g.: BNF) while a processor can be implemented from a 
> description.
> 
> Andrei Fangli
> 
> From: Aristotle Pagaltzis
> Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎20‎:‎53
> To: markdown-discuss@six.pairlist.net
> 
> * Andrei Fangli  [2014-09-07 10:45]:
> > When I hear Markdown processor I think of a specialized word/text
> > processor
> 
> That is not what it generally mean in RFCs. The XML specs speak of an
> XML processor, the Atom RFCs speak of an Atom processor, etc. So I think
> the terminology here is correct for an RFC.
> 
> (To me what you refer to is a “Markdown word processor”, esp considering
> that a word processor is called a *word* processor rather than, say, an
> RTF processor or a DOC processor.)
> 
> I’ll also defend the term on grounds of its meaning later, but let me
> first address the proposed alternatives:
> 
> > For me, Markdown implementation sounds a bit odd. Markdown is not
> > standardized nor is its specification clear enough
> 
> Agree.
> 
> > I’d simply name the specification (or flavour) and append “Translator”
> > at the end (e.g.: Github flavoured Markdown Translator, Common
> > Markdown Translator etc.).
> 
> That is specific to a use case. E.g. multiple MacOS X QuickLook plugins
> for Markdown preview exist; these are not translators, all they can do
> is display the document (or a portion of it). Internally they may use
> a translator, as most probably do, but they may just as well be written
> on top of a Markdown parser that merely creates an AST rather than any
> kind of output; either way it’s an implementation detail.
> 
> * Andrei Fangli  [2014-09-07 17:00]:
> > Parsing is all about syntactic analysis, a parser may well just return
> > true and false depending on whether the input is syntactically correct
> > or not.
> 
> Yes, agree: “parser” is not the right term.
> 
> It’s also not the right term because a translator need not necessarily
> parse the document. Markdown.pl doesn’t. So actually, “Markdown parser”
> in fact excludes the canonical Markdown… processor.
> 
> > I’m not very comfortable about calling them libraries if they are
> > actually executables or scripts.
> 
> Agree here also.
> 
> So…
> 
> Ultimately, to come back to the beginning of my mail, what you want to
> express is “a piece of software that will take Markdown and do something
> with it in some Markdown-rules-informed way”. You want to cover any kind
> of doing something, be it translating to another format or displaying
> the document or extracting something from it (e.g. indexing or counting
> words or whatever) or anything else. You want to cover any form in which
> software comes, be that a library, an executable, or just an incidental
> part of some larger library or application. And you want to allow for it
> implementing any fraction of the total Markdown rules (e.g. a Markdown
> word counter could ignore most inline formatting as punctuation without
> it making a difference in the result), and in whichever form it chooses
> (it could use parsing, or not).
> 
> I would argue that the only sufficie

Re: It's a Markdown processor, right?

[Andrei Fangli]

Sean wrote:

> I am trying to use uniform terms. An implementation that converts

Markdown content to another format--most typically HTML--is called...a

Markdown processor, right?



I was focusing on naming the software that takes text in format A and outputs 
it in format B (yep, just that use case). The XML specifications define that a 
XML Processor is something that recognizes the structure of a XML Document, 
validates it and offers access to its content (e.g.: by tree traversal since 
XML is hierarchical in nature). A software that simply translates from format A 
to B only recognizes, validates the structure of the text in format A and 
outputs the content in format B. If we were to apply an analogous definition 
for a Markdown Processor then the access to content is lost because the initial 
document as a whole is outputted in format B without having the chance to peak 
at its content. In that case we cannot name that software a processor, it may 
use one internally to get the job done.


In the case of a software that allows visualisation of Markdown documents prior 
to translation/export, eventually allowing editing, indexing, word count, page 
count etc., I agree, that no longer can be called a translator because it does 
much more. That software falls well in the terms of a word processor 
(specialized for Markdown in this case) as pointed out, however I’m not sure 
that’s what Sean was asking.


This discussion is turning out quite interesting as parsers require a grammar 
in a formal language (e.g.: BNF) while a processor can be implemented from a 
description.





Andrei Fangli





From: Aristotle Pagaltzis
Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎20‎:‎53
To: markdown-discuss@six.pairlist.net





* Andrei Fangli  [2014-09-07 10:45]:
> When I hear Markdown processor I think of a specialized word/text
> processor

That is not what it generally mean in RFCs. The XML specs speak of an
XML processor, the Atom RFCs speak of an Atom processor, etc. So I think
the terminology here is correct for an RFC.

(To me what you refer to is a “Markdown word processor”, esp considering
that a word processor is called a *word* processor rather than, say, an
RTF processor or a DOC processor.)

I’ll also defend the term on grounds of its meaning later, but let me
first address the proposed alternatives:

> For me, Markdown implementation sounds a bit odd. Markdown is not
> standardized nor is its specification clear enough

Agree.

> I’d simply name the specification (or flavour) and append “Translator”
> at the end (e.g.: Github flavoured Markdown Translator, Common
> Markdown Translator etc.).

That is specific to a use case. E.g. multiple MacOS X QuickLook plugins
for Markdown preview exist; these are not translators, all they can do
is display the document (or a portion of it). Internally they may use
a translator, as most probably do, but they may just as well be written
on top of a Markdown parser that merely creates an AST rather than any
kind of output; either way it’s an implementation detail.

* Andrei Fangli  [2014-09-07 17:00]:
> Parsing is all about syntactic analysis, a parser may well just return
> true and false depending on whether the input is syntactically correct
> or not.

Yes, agree: “parser” is not the right term.

It’s also not the right term because a translator need not necessarily
parse the document. Markdown.pl doesn’t. So actually, “Markdown parser”
in fact excludes the canonical Markdown… processor.

> I’m not very comfortable about calling them libraries if they are
> actually executables or scripts.

Agree here also.

So…

Ultimately, to come back to the beginning of my mail, what you want to
express is “a piece of software that will take Markdown and do something
with it in some Markdown-rules-informed way”. You want to cover any kind
of doing something, be it translating to another format or displaying
the document or extracting something from it (e.g. indexing or counting
words or whatever) or anything else. You want to cover any form in which
software comes, be that a library, an executable, or just an incidental
part of some larger library or application. And you want to allow for it
implementing any fraction of the total Markdown rules (e.g. a Markdown
word counter could ignore most inline formatting as punctuation without
it making a difference in the result), and in whichever form it chooses
(it could use parsing, or not).

I would argue that the only sufficiently generic term that will apply to
software in all of these cases is, in fact, “processor”.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: It's a Markdown processor, right?

[Chris Lott]

On Sat, Sep 6, 2014 at 3:55 PM, Sean Leonard  wrote:
> I have been using the term "Markdown processor"

In the context of RFCs, etc., that sounds correct. The other things
being discussed in this thread include things I think of as Markdown
editors and in other cases Markdown libraries.

c
--
Chris Lott 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

on the curve

[bowerbird via Markdown-Discuss]

john macfarlane said:

  When you try to fit a curve to a bunch of data points
  (which is what writing more precise rules for Markdown involves),
  the best fitting curve will probably not pass through all of the 

points.

you have shown a great ability to fit a curve to some disjointed points,
befitting the mental gymnastic flexibilities of a professor of 
philosophy.


now wipe that clean and do it again, with the object of plotting a curve
which is _simple_, and beautiful, and lean, and elegant, and graceful.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: It's a Markdown processor, right?

[Aristotle Pagaltzis]

* Andrei Fangli  [2014-09-07 10:45]:
> When I hear Markdown processor I think of a specialized word/text
> processor

That is not what it generally mean in RFCs. The XML specs speak of an
XML processor, the Atom RFCs speak of an Atom processor, etc. So I think
the terminology here is correct for an RFC.

(To me what you refer to is a “Markdown word processor”, esp considering
that a word processor is called a *word* processor rather than, say, an
RTF processor or a DOC processor.)

I’ll also defend the term on grounds of its meaning later, but let me
first address the proposed alternatives:

> For me, Markdown implementation sounds a bit odd. Markdown is not
> standardized nor is its specification clear enough

Agree.

> I’d simply name the specification (or flavour) and append “Translator”
> at the end (e.g.: Github flavoured Markdown Translator, Common
> Markdown Translator etc.).

That is specific to a use case. E.g. multiple MacOS X QuickLook plugins
for Markdown preview exist; these are not translators, all they can do
is display the document (or a portion of it). Internally they may use
a translator, as most probably do, but they may just as well be written
on top of a Markdown parser that merely creates an AST rather than any
kind of output; either way it’s an implementation detail.

* Andrei Fangli  [2014-09-07 17:00]:
> Parsing is all about syntactic analysis, a parser may well just return
> true and false depending on whether the input is syntactically correct
> or not.

Yes, agree: “parser” is not the right term.

It’s also not the right term because a translator need not necessarily
parse the document. Markdown.pl doesn’t. So actually, “Markdown parser”
in fact excludes the canonical Markdown… processor.

> I’m not very comfortable about calling them libraries if they are
> actually executables or scripts.

Agree here also.

So…

Ultimately, to come back to the beginning of my mail, what you want to
express is “a piece of software that will take Markdown and do something
with it in some Markdown-rules-informed way”. You want to cover any kind
of doing something, be it translating to another format or displaying
the document or extracting something from it (e.g. indexing or counting
words or whatever) or anything else. You want to cover any form in which
software comes, be that a library, an executable, or just an incidental
part of some larger library or application. And you want to allow for it
implementing any fraction of the total Markdown rules (e.g. a Markdown
word counter could ignore most inline formatting as punctuation without
it making a difference in the result), and in whichever form it chooses
(it could use parsing, or not).

I would argue that the only sufficiently generic term that will apply to
software in all of these cases is, in fact, “processor”.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: It's a Markdown processor, right?

[Andrei Fangli]

Parsing is all about syntactic analysis, a parser may well just return true and 
false depending on whether the input is syntactically correct or not.


I’m not very comfortable about calling them libraries if they are actually 
executables or scripts. They are either one of them but not both. Like you 
pointed out, a _Markdown_ library consists of a parser and one or more 
formatters (bare in mind that formatters are responsible for 
transforming/translating something from internal memory, an instance, into a 
format that can be physically stored on external memory, hdd, and later 
retrieved (e.g.: formatting an instance to XML and later reconstructing the 
instance from that same XML, just like one would save a word document to a 
.docx file and later “opening” it to continue writing the same document)). 
Eventually the library will allow the user to write his own formatters (e.g.: 
your library has a html formatter but I want to save as pdf, I need a way to 
extend your library in my application to write my own pdf formatter without 
writing the parser all over again).


Now the application/script that gets shipped with the library to make use of it 
from the command line is something apart from the library itself like you 
pointed out. How will this application/script be called since it can’t be 
parser or formatter? It does both things in a very specific order. I’m still 
willing to call it a translator because it takes file A and translates it to 
file B under a different format. The shipped application/script is nothing more 
than an _application_ to the Markdown library and if it’s open sourced it can 
serve as a tutorial for “here’s how you use this library”.


A library must primarily expose an interface and one or more dlls that can be 
referenced and consumed. If it’s just an exe that does all the work then I’m 
hesitant to calling it a library. I know that CLI Assemblies are either .dll or 
.exe and both can act as libraries but the primary intent of an .exe is to be 
executed and maybe referenced not the other way around.






Andrei Fangli





From: Waylan Limberg
Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎17‎:‎06
To: markdown-discuss@six.pairlist.net





Actually, on rereading my previous response, a realized that I also referred to 
it as a "library" (see http://en.m.wikipedia.org/wiki/Library_(computing)) 
which most (all?) markdown parsers are. So a "markdown editor" (a GUI app like 
MarkdownPad) would make calls to a "markdown library" to covert the markdown 
text typed by the user to HTML.




Strictly speaking, a library would generally consist of a "parser" and a 
"formatter". The parser parses the text ( identifies the different parts) and a 
formatter coverts those parts (the parse tree) into the final format. Therefore 
some libraries (like Pandoc) have multiple formatters, whereas others (most) 
only have one. Given the lack of choice of formatters, most people forget about 
the formatter part of the process. Thus the common nomenclature used is often 
"parser".




To add additional confusion most libraries also ship with a command line script 
which wraps the underlying library. That script usually defaults to parsing 
Markdown text and outputting HTML. So most people (perhaps incorrectly) think 
of that wrapping script as the final product and refer to the whole thing as 
the "parser".




So I would say that "library" is probably the technically correct term, but the 
generally accepted (and most widely understood) term is "parser".


Waylan Limberg


On Sep 7, 2014, at 9:39 AM, Waylan Limberg  wrote:





I would have to agree with Andrei mostly. Those of us that have implemented 
markdown libraries generally refer to them as implementations of a **parser**. 
"Processor" or "translator" are not words I've ever seen used.

Waylan Limberg


On Sep 7, 2014, at 3:50 AM, Andrei Fangli  wrote:





Hi,




I think not. When I hear Markdown processor I think of a specialized word/text 
processor (see http://en.wikipedia.org/wiki/Word_processor) which is more an 
application that helps you write stuff and print it, eventually export it to 
html. If you were to write an application that helps you write documents (e.g.: 
insert list, quote etc. via buttons/commands) and use Markdown as the 
underlying format would be a Markdown processor. If you would write an 
application that translates a Markdown document to html, that would be a 
Markdown translator and the whole process would be called translation (or 
Markdown to Html Translation). See http://en.wikipedia.org/wiki/Translation.




For me, Markdown implementation sounds a bit odd. Markdown is not standardized 
nor is its specification clear enough to draw a deterministic procedure for 
translating Markdown into html (or an Abstract Syntax Tree). You cannot say 
that there are multiple Markdown implementations if they do not yield the same 
output for any given input (if you would then I could swap implementations 
however I wish a

Re: It's a Markdown processor, right?

[Waylan Limberg]

Actually, on rereading my previous response, a realized that I also referred to 
it as a "library" (see http://en.m.wikipedia.org/wiki/Library_(computing)) 
which most (all?) markdown parsers are. So a "markdown editor" (a GUI app like 
MarkdownPad) would make calls to a "markdown library" to covert the markdown 
text typed by the user to HTML.

Strictly speaking, a library would generally consist of a "parser" and a 
"formatter". The parser parses the text ( identifies the different parts) and a 
formatter coverts those parts (the parse tree) into the final format. Therefore 
some libraries (like Pandoc) have multiple formatters, whereas others (most) 
only have one. Given the lack of choice of formatters, most people forget about 
the formatter part of the process. Thus the common nomenclature used is often 
"parser".

To add additional confusion most libraries also ship with a command line script 
which wraps the underlying library. That script usually defaults to parsing 
Markdown text and outputting HTML. So most people (perhaps incorrectly) think 
of that wrapping script as the final product and refer to the whole thing as 
the "parser".

So I would say that "library" is probably the technically correct term, but the 
generally accepted (and most widely understood) term is "parser".

Waylan Limberg

> On Sep 7, 2014, at 9:39 AM, Waylan Limberg  wrote:
> 
> I would have to agree with Andrei mostly. Those of us that have implemented 
> markdown libraries generally refer to them as implementations of a 
> **parser**. "Processor" or "translator" are not words I've ever seen used.
> 
> Waylan Limberg
> 
>> On Sep 7, 2014, at 3:50 AM, Andrei Fangli  wrote:
>> 
>> Hi,
>> 
>> I think not. When I hear Markdown processor I think of a specialized 
>> word/text processor (see http://en.wikipedia.org/wiki/Word_processor) which 
>> is more an application that helps you write stuff and print it, eventually 
>> export it to html. If you were to write an application that helps you write 
>> documents (e.g.: insert list, quote etc. via buttons/commands) and use 
>> Markdown as the underlying format would be a Markdown processor. If you 
>> would write an application that translates a Markdown document to html, that 
>> would be a Markdown translator and the whole process would be called 
>> translation (or Markdown to Html Translation). See 
>> http://en.wikipedia.org/wiki/Translation.
>> 
>> For me, Markdown implementation sounds a bit odd. Markdown is not 
>> standardized nor is its specification clear enough to draw a deterministic 
>> procedure for translating Markdown into html (or an Abstract Syntax Tree). 
>> You cannot say that there are multiple Markdown implementations if they do 
>> not yield the same output for any given input (if you would then I could 
>> swap implementations however I wish and get the same result).
>> 
>> I’d simply name the specification (or flavour) and append “Translator” at 
>> the end (e.g.: Github flavoured Markdown Translator, Common Markdown 
>> Translator etc.). That way it’s all clear what specification is used and 
>> what the intent of the application is. The real working horse behind a 
>> translator is a parser, once you have that you can pretty much do anything 
>> else. Saying that you have a Markdown parser is almost the same as saying 
>> that you have a Markdown translator, the remaining effort is close to a days 
>> work if you want to make it really fancy.
>> 
>> Andrei Fangli
>> 
>> From: Sean Leonard
>> Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎02‎:‎55
>> To: markdown-discuss@six.pairlist.net
>> 
>> Hello Markdown World,
>> 
>> Last month draft-seantek-text-markdown-media-type was adopted by the 
>> IETF Apps Area Working Group (APPSAWG). I am working on revising it.
>> 
>> I am trying to use uniform terms. An implementation that converts 
>> Markdown content to another format--most typically HTML--is called...a 
>> Markdown processor, right?
>> 
>> I have been using the term "Markdown processor". Just want to see if 
>> there is substantial disagreement about using that term to refer to the 
>> collective set of Markdown implementations out there.
>> 
>> Thanks,
>> 
>> Sean
>> 
>> PS I suppose it could also be called a "Markdown implementation". But 
>> I'm going to stick to my original nomenclature in the absence of a push 
>> for something else. For instance, graphical tools such as [MarkdownPad] 
>> may be implementations of Markdown, but they are not processors. 
>> MarkdownPad is a Markdown editor, that has built-in support for various 
>> Markdown processors (such as a GitHub Flavored Markdown processor, and a 
>> Markdown Extra processor).
>> 
>> [MarkdownPad]: http://markdownpad.com/
>> 
>> ___
>> Markdown-Discuss mailing list
>> Markdown-Discuss@six.pairlist.net
>> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>> ___
>> Markdown-Discuss mailing list
>> Markdo

Re: It's a Markdown processor, right?

[Waylan Limberg]

I would have to agree with Andrei mostly. Those of us that have implemented 
markdown libraries generally refer to them as implementations of a **parser**. 
"Processor" or "translator" are not words I've ever seen used.

Waylan Limberg

> On Sep 7, 2014, at 3:50 AM, Andrei Fangli  wrote:
> 
> Hi,
> 
> I think not. When I hear Markdown processor I think of a specialized 
> word/text processor (see http://en.wikipedia.org/wiki/Word_processor) which 
> is more an application that helps you write stuff and print it, eventually 
> export it to html. If you were to write an application that helps you write 
> documents (e.g.: insert list, quote etc. via buttons/commands) and use 
> Markdown as the underlying format would be a Markdown processor. If you would 
> write an application that translates a Markdown document to html, that would 
> be a Markdown translator and the whole process would be called translation 
> (or Markdown to Html Translation). See 
> http://en.wikipedia.org/wiki/Translation.
> 
> For me, Markdown implementation sounds a bit odd. Markdown is not 
> standardized nor is its specification clear enough to draw a deterministic 
> procedure for translating Markdown into html (or an Abstract Syntax Tree). 
> You cannot say that there are multiple Markdown implementations if they do 
> not yield the same output for any given input (if you would then I could swap 
> implementations however I wish and get the same result).
> 
> I’d simply name the specification (or flavour) and append “Translator” at the 
> end (e.g.: Github flavoured Markdown Translator, Common Markdown Translator 
> etc.). That way it’s all clear what specification is used and what the intent 
> of the application is. The real working horse behind a translator is a 
> parser, once you have that you can pretty much do anything else. Saying that 
> you have a Markdown parser is almost the same as saying that you have a 
> Markdown translator, the remaining effort is close to a days work if you want 
> to make it really fancy.
> 
> Andrei Fangli
> 
> From: Sean Leonard
> Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎02‎:‎55
> To: markdown-discuss@six.pairlist.net
> 
> Hello Markdown World,
> 
> Last month draft-seantek-text-markdown-media-type was adopted by the 
> IETF Apps Area Working Group (APPSAWG). I am working on revising it.
> 
> I am trying to use uniform terms. An implementation that converts 
> Markdown content to another format--most typically HTML--is called...a 
> Markdown processor, right?
> 
> I have been using the term "Markdown processor". Just want to see if 
> there is substantial disagreement about using that term to refer to the 
> collective set of Markdown implementations out there.
> 
> Thanks,
> 
> Sean
> 
> PS I suppose it could also be called a "Markdown implementation". But 
> I'm going to stick to my original nomenclature in the absence of a push 
> for something else. For instance, graphical tools such as [MarkdownPad] 
> may be implementations of Markdown, but they are not processors. 
> MarkdownPad is a Markdown editor, that has built-in support for various 
> Markdown processors (such as a GitHub Flavored Markdown processor, and a 
> Markdown Extra processor).
> 
> [MarkdownPad]: http://markdownpad.com/
> 
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: It's a Markdown processor, right?

[Andrei Fangli]

Hi,


I think not. When I hear Markdown processor I think of a specialized word/text 
processor (see http://en.wikipedia.org/wiki/Word_processor) which is more an 
application that helps you write stuff and print it, eventually export it to 
html. If you were to write an application that helps you write documents (e.g.: 
insert list, quote etc. via buttons/commands) and use Markdown as the 
underlying format would be a Markdown processor. If you would write an 
application that translates a Markdown document to html, that would be a 
Markdown translator and the whole process would be called translation (or 
Markdown to Html Translation). See http://en.wikipedia.org/wiki/Translation.


For me, Markdown implementation sounds a bit odd. Markdown is not standardized 
nor is its specification clear enough to draw a deterministic procedure for 
translating Markdown into html (or an Abstract Syntax Tree). You cannot say 
that there are multiple Markdown implementations if they do not yield the same 
output for any given input (if you would then I could swap implementations 
however I wish and get the same result).


I’d simply name the specification (or flavour) and append “Translator” at the 
end (e.g.: Github flavoured Markdown Translator, Common Markdown Translator 
etc.). That way it’s all clear what specification is used and what the intent 
of the application is. The real working horse behind a translator is a parser, 
once you have that you can pretty much do anything else. Saying that you have a 
Markdown parser is almost the same as saying that you have a Markdown 
translator, the remaining effort is close to a days work if you want to make it 
really fancy.



Andrei Fangli





From: Sean Leonard
Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎02‎:‎55
To: markdown-discuss@six.pairlist.net





Hello Markdown World,

Last month draft-seantek-text-markdown-media-type was adopted by the 
IETF Apps Area Working Group (APPSAWG). I am working on revising it.

I am trying to use uniform terms. An implementation that converts 
Markdown content to another format--most typically HTML--is called...a 
Markdown processor, right?

I have been using the term "Markdown processor". Just want to see if 
there is substantial disagreement about using that term to refer to the 
collective set of Markdown implementations out there.

Thanks,

Sean

PS I suppose it could also be called a "Markdown implementation". But 
I'm going to stick to my original nomenclature in the absence of a push 
for something else. For instance, graphical tools such as [MarkdownPad] 
may be implementations of Markdown, but they are not processors. 
MarkdownPad is a Markdown editor, that has built-in support for various 
Markdown processors (such as a GitHub Flavored Markdown processor, and a 
Markdown Extra processor).

[MarkdownPad]: http://markdownpad.com/

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss