Re: text/markdown effort in IETF (invite)
I would strongly recommend thinking through some of the political decisions before getting too far into this. 1) Markdown officially refers to the implementation and syntax created by John Gruber. 2) Markdown the perl implementation has not seen a bug fix in nearly 10 years. 3) Gruber's voice has been noticeably absent from the list for a long time, except for a comment that I recall as basically saying that Markdown was essentially feature complete as far as he was concerned. 4) Gruber has specifically said in the past that new projects could not coopt the Markdown name and would have to be clearly disambiguated. For example, I would assume that anyone other than Gruber could not create Markdown 2.0 to be the Markdown to rule them all... 5) I don't have numbers to back this up, but would strongly suspect that at this point very few people who think they use Markdown actually are. Most are using various derivatives that have made wide-ranging decisions on how to handle edge cases, etc. For most users, whose needs are very basic, the distinction is probably academic. But I would suggest that these distinctions are very important when it comes to official standards. I would propose that if there is to be an official standard based on Markdown, it would first require defining what Markdown is. To do that would (hopefully) require a more formalized description of the grammar. If Gruber were to sign off on allowing this to use the Markdown name, fantastic. But if not, a difficult decision would need to be made: 1) Build a standard based on Markdown.pl, bugs and all, and keep the Markdown name. 2) Develop a formalized version of the core syntax of Markdown, and base the standard on this. Unless it were to receive Gruber's blessing, it would have to be named something other than Markdown. 3) Continue to use the term Markdown as a vague term that refers to a loosely related collection of tools, leaving users to wonder why a given document works with one tool, and not others. At some point, a new common standard (e.g. Son of Markdown or whatever) may or may not arise that would require redefining all of this stuff. Granted, efforts to organize such a standard have thus far failed despite multiple enthusiastic discussions over the years on this list. My $.02 FTP On 7/9/14, 11:49 AM, Sean Leonard wrote: Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00. The proposal is already getting traction. Is there anyone on this list that is interested in participating or helping this effort? In particular we need to better understand and document what versions of Markdown exist, so that either Markdown as a family of informal syntaxes will start to converge, or if not, that Markdown variations have an easy way to be distinguished from one another. (See the flavor parameter discussed in the draft.) The draft is currently being discussed on apps-disc...@ietf.org. Kind regards, Sean Leonard Author of Markdown IETF Draft ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On 9 Jul 2014, at 17:07, Fletcher T. Penney wrote: Unless it were to receive Gruber's blessing, it would have to be named something other than Markdown. Really good summary Fletcher. I think unless someone steps up to create Son of Markdown as a project, we should all live with your third option (and I am just an inexpert user, would not be able to contribute any code/coding logic, so I'm not volunteering). We could go classical for the name: the latin would be 'subscribe' which is not very helpful. (Very bad literal classical) Greek for Son of Markdown would be something like 'Hypographides', retaining the allusion to Mark-down without actually using Gruber's name. The elusive acronym 'HGP' appeal to anyone?;) ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
Hello everyone, On 7/9/2014 9:58 AM, Dennis E. Hamilton wrote: I think the Internet draft is very clear. It is not a Standards Track project. It is a MIME-type registration proposal and the procedure for determination of flavors should satisfy whatever concerns there are. That is correct. My purpose in creating this first draft is not to make a Markdown standard; it is to identify Markdown content in a standardized way, namely, with text/markdown. In general, a MIME-type registration has to point to some place where there is a description of the format. These are not particularly definitive or authoritative in some cases, and this registration could fail for lack of something definitive. That is best dealt with on the IETF discussion list. Yes, this is a sticking point. Experienced IETFers will raise (and have raised) concerns about the authoritative-ness of the format. But IETFers have less experience with Markdown compared to you all, which is why I'm bringing it up here (and elsewhere). I have nothing to offer concerning official Markdown. It would appear that the term has already been appropriated as a common noun and there is no means to protect against that being otherwise. I am of the same view. Anyone can call anything Markdown--no one is stopping them. Just as anyone can call anything ASCII art or mashups (i.e., there might be an ASCII standard but what people do with it is totally different--it has become a cultural phenomenon). In the draft, I restricted the eligible formats to things based on John Gruber's original Markdown tool and syntax from 2004. Some realities are apparent, at least to me: 1. Markdown is a real thing. It's not plain text and it's not HTML--it's something different. (Heck, this list could be Markdown!) 2. People are using Markdown for real things of economic and social value. 3. Markdown is different from other _lightweight markup languages_. I.e., it's not reStructuredText, BBCode, javadocs, or Creole (wiki markup). But unlike the aforementioned examples, there is no authority that guides its development. (reStructuredText is a Python thing, for example, so the Python people are in charge of it.) 4. Things that are called Markdown (MultiMarkdown, GitHub Flavored Markdown, etc.) share more in common with each other than those in #3--therefore these things are related. 5. People are storing and exchanging Markdown-as-Markdown between systems. Not Markdown-as-plain-text, and not Markdown-as-HTML. Thus, there is a need for standardized interchange. -Sean ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
Le 9-juil.-2014 à 11:49, Sean Leonard dev+i...@seantek.com a écrit : Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00. The proposal is already getting traction. Is there anyone on this list that is interested in participating or helping this effort? In particular we need to better understand and document what versions of Markdown exist, so that either Markdown as a family of informal syntaxes will start to converge, or if not, that Markdown variations have an easy way to be distinguished from one another. (See the flavor parameter discussed in the draft.) The flavor parameter is a good idea in theory. I'm not sure it'll be very useful in general though. Nobody is going to annotate their file with the right flavor unless there's a tangible benefit, and I don't see what the benefit could be. Software that could do something useful with markdown-identified content will likely ignore the flavor part when parsing because no one wants to see incompatible flavor errors, especially when commonly used parts of the syntax are compatible anyway. Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
I disagree with the section quoted below. To my knowledge, Gruber has not officially trademarked Markdown. Markdown was a word before Gruber used it, but for different contexts. I am not a lawyer. However, in the world of honest people, the word Markdown as applied to lightweight text formats belongs to Gruber. Others may play off of it (PHP Markdown Extra, my own MultiMarkdown, etc.), but I can't create an entirely new syntax and call it Markdown. FTP On 7/9/14, 3:06 PM, Sean Leonard wrote: I am of the same view. Anyone can call anything Markdown--no one is stopping them. Just as anyone can call anything ASCII art or mashups (i.e., there might be an ASCII standard but what people do with it is totally different--it has become a cultural phenomenon). In the draft, I restricted the eligible formats to things based on John Gruber's original Markdown tool and syntax from 2004. -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
RE: text/markdown effort in IETF (invite)
Flavor was handled in HTML with the DTD, FWIW. -Original Message- From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Michel Fortin Sent: Wednesday, July 9, 2014 12:06 To: Discussion related to Markdown. Subject: Re: text/markdown effort in IETF (invite) [ ... ] Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca ___ 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
Re: text/markdown effort in IETF (invite)
On 7/9/2014 12:06 PM, Michel Fortin wrote: Le 9-juil.-2014 à 11:49, Sean Leonard dev+i...@seantek.com a écrit : Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00. The proposal is already getting traction. Is there anyone on this list that is interested in participating or helping this effort? In particular we need to better understand and document what versions of Markdown exist, so that either Markdown as a family of informal syntaxes will start to converge, or if not, that Markdown variations have an easy way to be distinguished from one another. (See the flavor parameter discussed in the draft.) The flavor parameter is a good idea in theory. I'm not sure it'll be very useful in general though. Nobody is going to annotate their file with the right flavor unless there's a tangible benefit, and I don't see what the benefit could be. Software that could do something useful with markdown-identified content will likely ignore the flavor part when parsing because no one wants to see incompatible flavor errors, especially when commonly used parts of the syntax are compatible anyway. Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. Ok so here is where I really want to focus and learn some stuff from the Markdown community. I am a fairly heavy Markdown user, but not a Markdown developer or maintainer [yet]. From what I have gathered of Markdown history as an observer, getting this into one standardized syntax is like herding cats. Someone complains about how _ and * interact, or how to do tables such-and-such a way, and then they go off and write a different tool that does it differently. Ultimately it's as much about style (which is very personal) as functionality. To make matters worse, Gruber isn't providing leadership, so anyone can write Son of Markdown and before you know it we'll have 50 different standards. http://xkcd.com/927/ If someone else manages to write a formal specification, I am happy to refer to that normatively in the (proposed) IETF work. If the community manages to coalesce around that spec, I am also happy to refer to that spec as the exclusive normative reference. But...you may as well boil the ocean. So I'm not going to attempt that. I just want to call the ocean for what it is, and it's not text/plain. :) Sean ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On 7/9/2014 12:06 PM, Michel Fortin wrote: Le 9-juil.-2014 à 11:49, Sean Leonard dev+i...@seantek.com a écrit : The flavor parameter is a good idea in theory. [...] Nobody is going to annotate their file with the right flavor unless there's a tangible benefit[...] [...] HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. About this flavors thing. I know there are several lists floating out there of different Markdown implementations and variants (or if you don't like them being called Markdown, you can call them Illegitimate Sons of Markdown™). Which list is the most complete? Can someone show me (or make for the community) a really comprehensive list, and agree to update it? When I wrote the -00 draft, I tried to follow the Media Type Registration Procedures. One requirement is to list required and optional parameters. Parameters are defined in RFC 6838 as companion data. See RFC 6838 and in particular, Sections 1, 4.2.1, and 4.3. All text/ types have at least one parameter: the charset. That is because all text data has to be interpreted according to a code (i.e., character set) that converts the bits of data into useful information. Nowadays we take Unicode (specifically UTF-8) for granted, but it's just not the case in reality. You can't just open a text file and hope for the best--you have to have /metadata/, express or implied, that tells you how to handle the blob of bits. The very fact that it is textual data has to be inferred from other things, such as the filename extension (when the data is in a file). A filename is just another piece of metadata. When dealing with HTML, the charset could determined at least six ways: 1. as express external metadata, when the Content-Type has a charset parameter in the HTTP header. 2. as implied external metadata, when the HTTP header is absent but the client infers it from other things (e.g., the server, the IP address, or by looking at the ccTLD). 3. as express internal metadata, with meta charset=iso-2022-jp or meta http-equiv=Content-Type content=text/html; charset=iso-2022-jp; or in the case of XHTML, ?xml version=1.0 encoding=iso-2022-jp?. 4. as express internal *data*, that is, the first bytes are 0xFF 0xFE (likely UTF-16LE), 0xFE 0xFF (likely UTF-16BE), or 0xEF 0xBB 0xBF (likely UTF-8). 5. as implied internal *data*, that is, take the first 256 bytes and try to see if it decodes to something approximating HTML soup using some common character sets; if it fits, you quit. 6. as express user preference, that is, I'm Japanese in Japan on a Windows machine, therefore on my browser, just assume everything is Shift-JIS. See...there are all these crazy options...because nobody standardized on the character set when HTTP/HTML was developed; people assumed it was US-ASCII and then shoehorned lots of zany ways to make it something else. At least with Markdown, we can probably safely eliminate #3 since Markdown is not intended to generate the head part of (X)HTML. The operating question is: What metadata (companion data) is /necessary/ to reflect the creator's intent with respect to the data? With Markdown, I think the answer is: you need the character set, and you need to know how to turn the text into HTML (or XHTML, PDF, RTF, MS Word/Office Open XML, or whatever). Markdown has no way to communicate the character set in the document (other than the Unicode Byte Order Marks, which is a generalized property about text streams, not specific to Markdown)--and it would be counterproductive to invent one. So that is a perfect example of relevant metadata. And the second one, is how to turn it into something else that the author wants. If it's not communicated, it's going to be implied. Implied means guessing and likely guessing wrong. Hopefully this makes sense. I want to be more educated about this. Thanks! Sean ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
RE: text/markdown effort in IETF (invite)
I think this comment [1] by Gruber on the mailing list in the past can shed some light on what the spec is (is it markdown.pl, the syntax rules on daringfireball.net, some mashup of various implementations, or something else?). According to Gruber, it is the syntax rules and that's it. If that is not good enough to get a mime-type, then I dont think there is anything else we can do. [1]: http://six.pairlist.net/pipermail/markdown-discuss/2008-February/001001.html -Original Message- From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Sean Leonard Sent: Wednesday, July 09, 2014 4:00 PM To: markdown-discuss@six.pairlist.net Subject: Re: text/markdown effort in IETF (invite) On 7/9/2014 12:06 PM, Michel Fortin wrote: Le 9-juil.-2014 à 11:49, Sean Leonard dev+i...@seantek.com a écrit : Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00. The proposal is already getting traction. Is there anyone on this list that is interested in participating or helping this effort? In particular we need to better understand and document what versions of Markdown exist, so that either Markdown as a family of informal syntaxes will start to converge, or if not, that Markdown variations have an easy way to be distinguished from one another. (See the flavor parameter discussed in the draft.) The flavor parameter is a good idea in theory. I'm not sure it'll be very useful in general though. Nobody is going to annotate their file with the right flavor unless there's a tangible benefit, and I don't see what the benefit could be. Software that could do something useful with markdown-identified content will likely ignore the flavor part when parsing because no one wants to see incompatible flavor errors, especially when commonly used parts of the syntax are compatible anyway. Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. Ok so here is where I really want to focus and learn some stuff from the Markdown community. I am a fairly heavy Markdown user, but not a Markdown developer or maintainer [yet]. From what I have gathered of Markdown history as an observer, getting this into one standardized syntax is like herding cats. Someone complains about how _ and * interact, or how to do tables such-and-such a way, and then they go off and write a different tool that does it differently. Ultimately it's as much about style (which is very personal) as functionality. To make matters worse, Gruber isn't providing leadership, so anyone can write Son of Markdown and before you know it we'll have 50 different standards. http://xkcd.com/927/ If someone else manages to write a formal specification, I am happy to refer to that normatively in the (proposed) IETF work. If the community manages to coalesce around that spec, I am also happy to refer to that spec as the exclusive normative reference. But...you may as well boil the ocean. So I'm not going to attempt that. I just want to call the ocean for what it is, and it's not text/plain. :) Sean ___ 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
Re: text/markdown effort in IETF (invite)
Le 9-juil.-2014 à 16:08, Sean Leonard dev+i...@seantek.com a écrit : The operating question is: What metadata (companion data) is /necessary/ to reflect the creator's intent with respect to the data? With Markdown, I think the answer is: you need the character set, and you need to know how to turn the text into HTML (or XHTML, PDF, RTF, MS Word/Office Open XML, or whatever). Indeed. Markdown has no way to communicate the character set in the document (other than the Unicode Byte Order Marks, which is a generalized property about text streams, not specific to Markdown)--and it would be counterproductive to invent one. So that is a perfect example of relevant metadata. Fun fact: PHP Markdown is mostly encoding agnostic. It understands UTF-8 sequences but any byte that is not a valid UTF-8 sequence is treated as a character in itself. It's only relevant when converting tabs into spaces however, and only if you have non-ASCII characters before the tab. So whatever the input encoding is becomes the output's encoding (this works for HTML). Naturally, it's good to know the input's encoding if you want to know the output's. So obviously it's a good idea to specify the text encoding even though the parser itself doesn't need it, so you know the resulting document's encoding. That's not really relevant though. And the second one, is how to turn it into something else that the author wants. If it's not communicated, it's going to be implied. Implied means guessing and likely guessing wrong. Ideally you'd use the exact same version of the same parser the author used to interpret the document in the first place. Or you could be loose and use another version of the same parser. Or you could be loose and use another parser claiming to be of the same flavor. Or you could be loose and use another parser claiming to be of a superset of the given flavor. Or you could be loose and use another Markdown parser. It's a spectrum. Each step down will increase the likeliness of something going wrong. Hopefully this makes sense. I want to be more educated about this. This makes perfect sense, but I fear there's no good answer to your second question. Since you want to know more, here's some insight. It's important to understand that there is no notion of invalid Markdown input. As an implementer every time you fix what looks like a parsing bug to you or add a feature you're also breaking some valid input that was producing something else before. The implementer will usually only choose to break valid input that was deemed very unlikely to ever have been used before, but there's no way to know for sure (and no reliable way to measure impact either). So if you really really want to be sure things are parsed in the intended way, you should use the closest version possible of the same parser as the creator of the document was using. Also, subtle changes can make things technically incompatible. For instance, Markdown Extra is mostly a superset of the original Markdown feature-wise, except for one small incompatible change: underscore emphasis within a word is disallowed. This was a deliberate change to fix some problems users were having with words that contained underscore. So even though most people would consider Markdown Extra as a superset of Markdown, it technically isn't. Other implementers might do the same thing but consider it as a bug fix instead and tell their users implementation implements the original syntax. Babelmark 2 will tell you that implementations are pretty much evenly split on this: http://johnmacfarlane.net/babelmark2/?normalize=1text=word_with_emphasis You'll even see that Pandoc implements both behaviour depending on whether you're in strict mode or not. Something stranger happens with the shortcut reference syntax: http://johnmacfarlane.net/babelmark2/?normalize=1text=%5Blink%3F%5D%0A%0A%5Blink%3F%5D%3A+http%3A%2F%2Flink.x%2F It's pretty much universally supported. It comes from a Markdown.pl beta that was never formally released but which is widely in use. If you were to go to the Markdown website and use the download link, you won't get the beta and it won't work. And while the second one is feature-wise a superset of the first, technically it could in some rare situations break documents, turning square bracketed text into links where it shouldn't: Someone on [street Ivanhoe Carol][sIC] told me this: This is bad [sic]. [sIC]: http://sic.sickdomain I sure wish things would be simpler. But as things are now, I have a hard time identifying what flavor could mean. Should Markdown.pl-1.0.1 be a flavor on its own? -- Michel Fortin michel.for...@michelf.ca http://michelf.ca ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
Hi, Michel Fortin said: Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. Yes basically. And it's why Ciro Santilli has done an amazing work upon the [test suite][1] I have started. [1]: https://github.com/karlcow/markdown-testsuite The issue with Markdown and its flavors is that it is mainly used: * asan input format for something else, aka in a converter scenario * more than an exchange format with multiple emitters/consumers needing interoperability. It starts to change with the rise of some clients and this ties to the mime-type issue: I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. Yup agreed. A [MIME type][2] is useful in the case of exchange format when an emitter and a receiver needs to understand what they are exchanging. In the case of the input format, there is no issue because the environment is constrained. When you play with multiple clients, the interoperability story becomes interesting. [2]: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 -- Karl Dubost http://www.la-grange.net/karl/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Markdown as genericized
Markdown has become genericized (and was never registered or defended as intellectual property). See http://en.wikipedia.org/wiki/Generic_trademark The idea that Gruber has to (or even ever would) sign off on anything is counter to his behavior and stated opinion on the matter. His historical involvement and contemporary non-involvement should not become an impediment or even an issue for markdown-related development. Sincerely, -- Jeff McNeill ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown as genericized
I personally agree with this and I would be happy to continue working within the W3C or elsewhere to get a baseline standard defined. On Wed, Jul 9, 2014 at 8:20 PM, Jeff McNeill j...@jeffmcneill.com wrote: Markdown has become genericized (and was never registered or defended as intellectual property). See http://en.wikipedia.org/wiki/Generic_trademark The idea that Gruber has to (or even ever would) sign off on anything is counter to his behavior and stated opinion on the matter. His historical involvement and contemporary non-involvement should not become an impediment or even an issue for markdown-related development. Sincerely, -- Jeff McNeill ___ 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
Re: Markdown as genericized
If this in response to my earlier comment, as stated, I refer to the behavior of honest people… not the behavior of those who would refer only to the law without consideration of what is clearly right or wrong. Markdown was created by John Gruber, and until he states otherwise, he owns the name. To take it away on the basis of rules of intellectual property rules may or may not be legal, but that doesn't make it right. And in fact, Gruber has clearly stated that he did not intend to give away the Markdown name: http://blog.gmane.org/gmane.text.markdown.general/month=20080301/page=13 I am not aware of any subsequent recanting of this opinion -- please provide a reference if you believe otherwise. I would not support any effort to coopt the Markdown name without Gruber's approval. If this is anyone's intent, count me out. Hopefully the developers of the other major Sons of Markdown will follow suit, but I can speak only for myself. FTP -- Fletcher T. Penney fletc...@fletcherpenney.net On Jul 9, 2014, at 9:20 PM, Jeff McNeill j...@jeffmcneill.com wrote: Markdown has become genericized (and was never registered or defended as intellectual property). See http://en.wikipedia.org/wiki/Generic_trademark The idea that Gruber has to (or even ever would) sign off on anything is counter to his behavior and stated opinion on the matter. His historical involvement and contemporary non-involvement should not become an impediment or even an issue for markdown-related development. Sincerely, -- Jeff McNeill ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss smime.p7s Description: S/MIME cryptographic signature ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
You appear to be testing MultiMarkdown in standard mode, rather than compatibility mode (`-c`). If you're going to test against standard Markdown syntax you should use compatibility mode as it disables the additional features that alter the output (e.g. smart typography, anchors on headers, etc.). When doing this properly, it appears that MMD fails only one test, which I will work on. FTP -- Fletcher T. Penney fletc...@fletcherpenney.net On Jul 9, 2014, at 9:18 PM, Karl Dubost k...@la-grange.net wrote: Hi, Michel Fortin said: Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. Yes basically. And it's why Ciro Santilli has done an amazing work upon the [test suite][1] I have started. [1]: https://github.com/karlcow/markdown-testsuite The issue with Markdown and its flavors is that it is mainly used: * asan input format for something else, aka in a converter scenario * more than an exchange format with multiple emitters/consumers needing interoperability. It starts to change with the rise of some clients and this ties to the mime-type issue: I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. Yup agreed. A [MIME type][2] is useful in the case of exchange format when an emitter and a receiver needs to understand what they are exchanging. In the case of the input format, there is no issue because the environment is constrained. When you play with multiple clients, the interoperability story becomes interesting. [2]: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 -- Karl Dubost http://www.la-grange.net/karl/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss smime.p7s Description: S/MIME cryptographic signature ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
* Sean Leonard dev+i...@seantek.com [2014-07-09 22:10]: Markdown has no way to communicate the character set in the document (other than the Unicode Byte Order Marks, which is a generalized property about text streams, not specific to Markdown)--and it would be counterproductive to invent one. So that is a perfect example of relevant metadata. And the second one, is how to turn it into something else that the author wants. If it's not communicated, it's going to be implied. Implied means guessing and likely guessing wrong. Yet guessing wrong is largely without consequence. There are really no syntax features that affect the document’s rendering non-locally. If part of a document is written with unsupported syntax, only that part will render incorrectly, but the other parts will come out fine. And there are no large overlapping surfaces among the syntaxes of the various extensions (esp. those for very different document features), which makes unsupported syntax unlikely to appear to have been intended to be rendered as some completely dissimilar feature. So you will get a document that differs from the author’s intent in some way. But it will be clear *where* the differences are and you will still get all of the data in *some* form, quite possibly fully intelligible if not pretty. And because of the primary goal of Markdown to be human-readable in its source form, there is always an easy and cheap last resort: view source. Bottom line, misrendering a document due to wrong choice of flavour is annoying but inconsequential, due to the very nature of Markdown. Therefore the flavour parameter ought to be considered nothing more than loosely informative, and the processor should just render the document to the best of its ability regardless of the flavour specified. It MAY use the parameter value to adapt to the document, in RFC 2119 lingo, but ought not be bound by it. Furthermore, an absent flavour parameter ought to mean that the flavour is unspecified, not that it is any particular default flavour; i.e. the choice of flavour in that case ought to be up to the processor. Lastly, the spec should mention (as informal guidance to implementors) that applications containing Markdown processors which have any chance of being exposed to source documents of unknown flavour should, if at all possible, provide a means for the user to view the source Markdown document in unformatted form. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
Aristotle, Le 10 juil. 2014 à 12:06, Aristotle Pagaltzis pagalt...@gmx.de a écrit : Lastly, the spec should mention (as informal guidance to implementors) that applications containing Markdown processors which have any chance of being exposed to source documents of unknown flavour should, if at all possible, provide a means for the user to view the source Markdown document in unformatted form. Very good point. Added to https://github.com/karlcow/markdown-testsuite/issues/59 -- Karl Dubost http://www.la-grange.net/karl/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown as genericized
On 7/9/2014 6:32 PM, Fletcher T. Penney wrote: And in fact, Gruber has clearly stated that he did not intend to give away the Markdown name: http://blog.gmane.org/gmane.text.markdown.general/month=20080301/page=13 I don't want to wade into this what is Markdown and who gets to approve it thing. But to the extent that this is what we know of John Gruber, it was said: Yuri Takhteyev: /If/ Gruber decides he despies our specification, we should simply call it something other than Markdown. John Gruber: Just to be clear: in that case, you *must* call it something other than Markdown. Means: /If/ Gruber decides he despises our specification, /then in that case/, John Gruber says that you *must* call it something other than Markdown. All this is to say that Gruber does not say what will happen if he does not despise someone's specification. So unless he says that he despises your specification, we have nothing authoritative from him. And even if we did, I don't know if it matters. The only other thing we have is that the original Markdown Perl script uses a 3-clause BSD-style license, which says: * Neither the name Markdown nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. To be clear: this is a copyright license, and it only attaches to the software Markdown.pl, Markdown Readme.text, and License.text in the distribution (reflexively). Derived means derived in the copyright law sense, as in, you prepared a derivative work. Taking the techniques of a software /or its documentation/ and implementing the same techniques (as in, doing what the Syntax document says Markdown is supposed to do) using your own expression, is neither a copyright law violation nor a trademark issue. Only patent law can prevent you from taking techniques and practicing them elsewhere. I don't know if there is much to argue about. Perhaps nobody can rev Markdown.pl and release Markdown 2.0 and call it Markdown 2.0 (but obviously, they can call it something else). Interestingly, the Syntax webpage at http://daringfireball.net/projects/markdown/syntax has no license attached; all we know is that it is Copyright © 2002--2014 The Daring Fireball Company LLC. Just because you invent words (or invent capitalizations to words) doesn't mean that you can now prevent others from using those words, unless of course you register them as trademarks, and enforce your rights. The overall point being...ok, you can't call your specification Markdown, but you can call it Markdown Syntax, since that isn't Markdown. g And there is such as thing as Markdown syntax--it is the collection of techniques that one can use with inputs to Markdown.pl /or other tools/, and expect certain outputs. I think this is easy enough to understand if you replace Markdown with grep. grep is a tool. When you refer to grep as a noun, you're referring to the command-line utility. But there is such a thing as grep syntax and grep syntax is a collection of techniques that are implemented in the original grep by Ken Thompson, as well as replacements to grep. Just as FTP pointed out, some Markdown tools (MultiMarkdown) have modes or switches (-c) that make the tool more compatible with the original Markdown, versus more feature-some. Similarly some grep tools have similar switches to enable or disable particular behaviors of their implementations. -Sean ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On 7/9/2014 8:06 PM, Aristotle Pagaltzis wrote:
* Sean Leonard dev+i...@seantek.com [2014-07-09 22:10]:
Markdown has no way to communicate the character set in the document
(other than the Unicode Byte Order Marks, which is a generalized
property about text streams, not specific to Markdown)--and it would
be counterproductive to invent one. So that is a perfect example of
relevant metadata. And the second one, is how to turn it into
something else that the author wants. If it's not communicated, it's
going to be implied. Implied means guessing and likely guessing
wrong.
Yet guessing wrong is largely without consequence.
There are really no syntax features that affect the document’s rendering
non-locally. If part of a document is written with unsupported syntax,
only that part will render incorrectly, but the other parts will come
out fine.
There are two use cases that I am particularly interested in:
#1 You put .md files in a project (readme.md, etc.). These .md files are
then passed around among project users, which may include developers,
copy-writers, copy-editors, etc. They need to be sure that the readme.md
is treated in the same way, which ought to be communicated with the
data. If one person edits the document in UTF-8 and commits and another
person edits the document in ISO-8859-1, you're going to have problems.
#2 You have some app (let's say some web forum for example, but it
literally could be anything, an electronic health record, some national
criminal records, whatever) and you export data from the app. Say to
some structured data format like XML or a sqlite database. Part of data
liberation or backup or whatever. You want to get whatever your users
actually input into the fields--not the HTMLized versions. So you need
to annotate the blobs of data as Markdown, since users like to upload
various kinds of data (Word docs, JPEG images, MP4 videos, bits of text
like names of individuals, whatever).
In both cases, rendering matters non-locally.
And there are no large overlapping surfaces among the syntaxes of the
various extensions (esp. those for very different document features),
which makes unsupported syntax unlikely to appear to have been intended
to be rendered as some completely dissimilar feature.
As someone new to Markdown development, I really want to see some
comprehensive references (since authority in Markdown-land is notably
absent). Besides, since Markdown is such a free-for-all, someone could
easily write a Markdown processor that turns (!) into
scriptalert('hello!');/script.
So you will get a document that differs from the author’s intent in some
way. But it will be clear *where* the differences are and you will still
get all of the data in *some* form, quite possibly fully intelligible if
not pretty.
For what we might call sensible flavors of Markdown, yes. But the
author's intent may be poorly represented when processed through a tool
that injects lolcat pictures every third word. Or, the author's intent
may be very well-represented.
The point is...we don't know what the author's intent is, /unless the
author tells us/. And I think we need some more metadata to make the
author's intent clear.
And because of the primary goal of Markdown to be human-readable in its
source form, there is always an easy and cheap last resort: view source.
This is a goal. Agreed.
Therefore the flavour parameter ought to be considered nothing more than
loosely informative, and the processor should just render the document
to the best of its ability regardless of the flavour specified. It MAY
use the parameter value to adapt to the document, in RFC 2119 lingo, but
ought not be bound by it.
I would reword this:
The flavor parameter informs recipients of the author's intent. The processor
should just render the document to the best of its ability regardless of the
flavor specified. It SHOULD
use the parameter value to adapt to the document.
I don't know what should happen if the flavor is absent. I am trying to
understand. Let me put it this way: if you come across un-annotated
Markdown in the wild (as in, not attached to any processing scripts,
instructions, directions, whatever), what do you do? Guess?
Furthermore, an absent flavour parameter ought to mean that the flavour
is unspecified, not that it is any particular default flavour; i.e. the
choice of flavour in that case ought to be up to the processor.
The choice of how to act on the Markdown is /always/ up to the
processor...so...probably. It just may not represent the author's intent.
Between this and the Gruber discussion, I need to get used to this idea
that guessing is a normative part of Markdown culture. :)
Lastly, the spec should mention (as informal guidance to implementors)
that applications containing Markdown processors which have any chance
of being exposed to source documents of unknown flavour should, if at
all possible, provide a means for the user to view
Re: text/markdown effort in IETF (invite)
+++ Michel Fortin [Jul 09 14 18:07 ]: Fun fact: PHP Markdown is mostly encoding agnostic. It understands UTF-8 sequences but any byte that is not a valid UTF-8 sequence is treated as a character in itself. It's only relevant when converting tabs into spaces however, and only if you have non-ASCII characters before the tab. Small amendment: There are at least two places where the difference between utf-8 and latin1 matters: tab expansion (as you note) and reference links, since these are stipulated to be case insensitive. (Case conversion is sensitive to the encoding.) ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
