It's a Markdown processor, right?

[Aristotle Pagaltzis]

* Andrei Fangli <andrei_fangli at hotmail.com> [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 <andrei_fangli at hotmail.com> [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 // <http://plasmasturm.org/>