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 at six.pairlist.net





* 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/>
_______________________________________________
Markdown-Discuss mailing list
Markdown-Discuss at six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20140907/938f7a23/attachment-0001.html>