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 <andrei_fangli at hotmail.com> 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 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
> _______________________________________________
> 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/3d0915c5/attachment.html>