Re: It's a Markdown processor, right?
* 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
on the curve
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?
On Sat, Sep 6, 2014 at 3:55 PM, Sean Leonard dev+i...@seantek.com 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 ch...@chrislott.org ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: It's a Markdown processor, right?
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
Re: It's a Markdown processor, right?
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
Re: It's a Markdown processor, right?
* Waylan Limberg waylan.limb...@icloud.com [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 // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
