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_fan...@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@six.pairlist.net > > * Andrei Fangli <andrei_fan...@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_fan...@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@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