Link syntax (was: definition lists?)
Tangentially, I notice that this post by Waylan uses a link syntax which doesn't seem to be defined by http://daringfireball.net/projects/markdown/syntax#link but seems to work in some implementations at http://babelmark.bobtfish.net/ - that is, from the git repo [1] instead of from the git repo [1][] or from the [git repo] [1]. The link definition is then [1]: http://gitorious.org/projects/python-markdown/repos/mainline Which of the outputs generated at http://babelmark.bobtfish.net/?markdown=checkout+from+the+git+repo+[1]%0D%0Aat+commit+e968bbf+(on+Nov+6)%2C%0D%0A%0D%0A[1]%3A+http%3A%2F%2Fgitorious.org%2Fprojects%2Fpython-markdown%2Frepos%2Fmainlinesrc=1dest=2 (also available at http://tinyurl.com/6hq7ut in case the full URI gets mashed) is considered 'expected'? IIUC, what I'll refer to Waylan's syntax makes any text enclosed in square brackets into a candidate for a link; the parser then searches for a matching link definition. I'm undecided whether the simplicity of this syntax offsets the risk of breaking existing documents. A link will only be generated if a matching link definition is found, IIUC, so perhaps this risk is acceptably low? Please point me to a previous discussion if available, I couldn't find one in the archives. Regards, Thomas. Waylan Limberg wrote on 2008/11/14 20:37: It's in the works. We had a working solution last week, but then refactored the core this week, so I have to refactor the definition list stuff. If you want it right now, your free to checkout from the git repo [1] at commit e968bbf (on Nov 6), or wait a few more days for me to get the refactor done and have the latest and greatest. One thing is for sure, I will have something included in the next release which I anticipate happening soonish. [1]: http://gitorious.org/projects/python-markdown/repos/mainline On Fri, Nov 14, 2008 at 1:26 PM, Andreas Åkre Solberg [EMAIL PROTECTED] wrote: Any way of writing definition lists? Andreas ___ 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: spaces and newlines before list markers (was: evolving the spec)
Joseph Lorenzo Hall wrote on 2008/03/02 18:26: On Sun, Mar 2, 2008 at 10:00 AM, John Fraser [EMAIL PROTECTED] wrote: Tightening up indentation rules is definitely a breaking change, and I don't see any payoff for users here. If anything, we should be making indentation rules more lenient. My only desire is to figure out a way to allow the whitspace-before-list-marker and also avoid the more general class of bugs where a list is triggered by a sentence ending with a number on an indented newline. The reference citation I sent out on another thread is one example but anything of the following form will trigger this: * This is a list item with a hanging indent ending with a number, 4. The rest is considered a child of a new ordered list, no matter what I do to this paragraph (other than rephrase to get rid of the hanging-indented digit+dot). Which produces ul liThis is a list item with a hanging indent ending with a number, olliThe rest is considered a child of a new ordered list, no matter what I do to this paragraph (other than rephrase to get rid of the hanging-indented digit+dot)./li/ol/li /ul Is this something we're comfortable with? If not, can we come up with something that avoids this? best, Joe Actually, when I first read your example I was confused -- I thought '4.' was a second-level bullet point, despite the comma on the preceding line. If a human (admittedly a very tired one) can make this interpretation, I can live with a Markdown processor making it also. John's proposed approach in http://six.pairlist.net/pipermail/markdown-discuss/2007-July/000690.html seems to fit well with what a naive (tired) human might expect to happen. As ever, YMMV. -- Thomas. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: evolving the spec (was: forking Markdown.pl?)
Waylan Limberg wrote on 2008/02/29 15:56: With all this discussion about evolving the spec, I think we want to remember the philosophy behind Markdown to begin with. Go re-read the Overview[1] of the syntax rules. ... snip ... Take the discussion a short time ago on this list regarding whitespace allowed at the start of a list item. A quick read of the rules would indicate the the `*` or number should be the first item on that line. In practice, markdown.pl allows up to 3 spaces at the start of a list item. While J.G. agreed (IIRC) that that probably is a bug that should be fixed, we learned through the course of that conversation that a number of people actually are relying on that bug as a feature, and in fact, if the bug was fixed, their documents would break. FWIW, I (as a humble Markdown user) am in that group. Why? Because it is how I _expect_ a list to be formatted in ASCII, and I tentatively suggest may be what many others expect also. Certainly it's a form I've seen used widely. If I'm not thinking about correct markdown syntax, but just what comes naturally when writing a quick email; I might say Cases in point: * Feynman * Dirac * Bohr without thinking about inserting an extra line before the list to ensure that it gets correctly processed, aligning asterisks with zero indent so they get correctly processed, yada yada. Part of the joy of markdown (that sounds a little over-caffeinated) is precisely the laxity that makes it, I gather, so hard to implement. think Markdown 2.0 is a good idea. By moving to 2.0, we don't have to worry about backward compatibility (Markdown 2.0 should not allow those 3 spaces). That's one of the scarier suggestions I've read today. So all my documents would need to be pre-processed to conform to the new markdown-2-0-strict syntax? May I ask why? Having a spec/ruleset/syntax definition seems an admirable goal; does this necessarily imply that, for example, you should not be able to begin a list item with zero to three spaces, at your discretion? This seems rather at odds with the overall theme of your mail, with which I heartily agree. Please bear in mind I know nothing about the implementation complexity of this: if it is infeasible to have such a loose approach, I'll still write in Markdown instead of DocBook/HTML, and will simply learn the new syntax. -- Thomas ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: evolving the spec (was: forking Markdown.pl?)
Joseph Lorenzo Hall wrote on 2008/02/29 17:14: On Fri, Feb 29, 2008 at 8:52 AM, Thomas Nichols [EMAIL PROTECTED] wrote: Having a spec/ruleset/syntax definition seems an admirable goal; does this necessarily imply that, for example, you should not be able to begin a list item with zero to three spaces, at your discretion? This seems rather at odds with the overall theme of your mail, with which I heartily agree. As a slightly-OT aside, there's another view on this spaces before a list item issue that sees it as a bug. When I write a list of references in a academic paper, I do so with list items. I do a hanging indent where the rest of the reference is indented by two or three spaces, like so: * Aslam, J. A., Popa, R. A., Rivest, R. L. (2007). On estimating the size and confidence of a statistical audit, USENIX/ACCURATE Electronic Voting Technology Workshop 2007. Retrieved February 24, 2008. from http://www.usenix.org/events/evt07/tech/full_papers/aslam/aslam.pdf. Markdown sees that 2008. as a list item. Perhaps a first step to resolving the much broader question of whether to define a formal grammar, a ruleset, a textual description or whatever could be just to reach consensus on some of these questions? As Yuri mentioned, code block syntax is still an open loop, as is indentation before list item marker and many others. In the interests of starting to close some of these loops, I'll kick this one to a separate thread - and if we can reach consensus, it can be documented and referenced in any spec/docs/implementations anyone cares to create. Once we have a set of these consensus opinions hammered out, it makes some sense to me that we then start talking about a spec, a set of rules and so on - IETF-style, but perhaps with rather shorter RFCs... -- Thomas. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
spaces and newlines before list markers (was: evolving the spec)
Joseph Lorenzo Hall wrote on 2008/02/29 17:14: As a slightly-OT aside, there's another view on this spaces before a list item issue that sees it as a bug. When I write a list of references in a academic paper, I do so with list items. I do a hanging indent where the rest of the reference is indented by two or three spaces, like so: * Aslam, J. A., Popa, R. A., Rivest, R. L. (2007). On estimating the size and confidence of a statistical audit, USENIX/ACCURATE Electronic Voting Technology Workshop 2007. Retrieved February 24, 2008. from http://www.usenix.org/events/evt07/tech/full_papers/aslam/aslam.pdf. Markdown sees that 2008. as a list item. Ok: that's what Markdown.pl sees. Do any of _us_ see it like that? For a human, I think this is easy. Even removing the comma from the preceding line, I think there's enough 'ASCII layout' information here for an untrained reader to tell from a casual glance that '2008' is not intended to be a list item. So do we need a full-on AI engine to be able to build a parser to handle this? Or can we think up some simple algorithm - there must be a change of indent for a sub-bullet, perhaps, or a new bullet must be at the same level as the preceding one? If 2008 were indented by a space, then I think it **should** be a new item, a sub-bullet. Maybe that's because I'm used to working with suboptimal tools (web browsers for blog comments have already been mentioned) which don't automatically indent the paragraph beneath the bullet point as in this example. In fact, I often see a blank line separating bullets instead. * Inertial-Electrodynamic Fusion (IEF) Device - Energy/Matter Conversion Corporation (EMC2). The fusion process recommended by Dr. Bussard takes boron-11 and fuses a proton to it, producing, in its excited state, a carbon-12 atom. This excited carbon-12 atom decays to beryllium-8 and helium-4. * Bussard's website, asking for donations to fund further research * American Scientist article mentioning the founding of EMC2 Again, I think each of us understands these are bullets. I'm writing this in Thunderbird, just typing '*' instead of pressing the 'bullet' button', so I'm getting word-wrap but no automatic indentation (though MTAs etc. may reformat the message later). They follow the typographic approach of indenting the first line of the para; compare with the example Joe quoted which outdents the bullet points and then indents the whole paragraph beneath it. Can we consider these to be two equally valid approaches? On a personal note, what inspired me about Markdown was John Gruber's [Dive into Markdown][] article. Possibly relevant here: In fact, I love writing email. Email is my favorite writing medium. I’ve sent over 16,000 emails in the last five years. The conventions of plain text email allow me to express myself clearly and precisely, without ever getting in my way. Thus, Markdown. Email-style writing for the web. ... The typographic constraints of plain text — a single typeface, in a single size, with no true italics or bold — are very much similar to the constraints of a typewriter. That's what I'm after ... to be able to use the conventions of plain text email when creating content; and conventions are often pretty woolly, so creating a formal ruleset from them is probably going to be tough. In this instance, though, I haven't yet understood why Markdown should not continue to support the following from the [syntax page][], List markers typically start at the left margin, but may be indented by up to three spaces. List markers must be followed by one or more spaces or a tab. As a (weak) analogy, SQL has both a laboriously detailed specification and a surprisingly loose query syntax, allowing noise words and using intelligent defaults to capture intent wherever possible. TIMTOWTDI, especially when writing an email. So -- any reasons why we should need to tighten the spec? Or can we simply document it formally, with a grammar, test suite and so on to make sure that the expected behaviour is always known, and ideally is consistent with email convention? -- Thomas. [Dive into Markdown]: http://daringfireball.net/2004/03/dive_into_markdown [syntax page]: http://daringfireball.net/projects/markdown/syntax#list ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: spaces and newlines before list markers (was: evolving the spec)
Waylan Limberg wrote on 2008/03/01 6:12: Hmm, I don't remember reading that before. Was it always there? Not sure. Been there for a cuple of years at least, I think. Anyway, to be honest this has been the hardest thing about markdown for me to wrap my head around (and probably why I picked it as an example in the other discussion). The way I always understood it, indenting in Markdown is done in increments of 4. Therefore, in my mind, the only amounts of indent allowed should be 0, 4, 8, 12, 16, ... and so on. It would never even occur to me to use any other amounts of indent for any reason - ever. And, in fact, I had never tried it until someone brought it up here on the list. With the exception of the it makes copy and pasting easier argument, I'll probably never understand it. Thats just the way my mind works. Nothing against those who think differently. I use increments of two - but the same principle applies I think. Using ~ for spaces for clarity: ~~1. Item One a. One A b. One B ~~2. Item Two ... ... and unsurprisingly some (maybe all) of the Markdown implementations I use have a fit about this -- they interpret the 4 space indent as implying a precodeblock. In this context, though, I think a human would see immediately what is intended. Perhaps M-Spec parts 1 or 2 could as well? And, in fact, reading Gruber's Dive into Markdown it would seem reasonable that one could conceivably take any well crafted email and run it through a markdown parser and get some decent html. Obviously, in practice things don't work so well. In the end consesions have to be made on both sides. I won't enforce my restrictive view of indentation on the community at large, and perhaps those who like to indent secondary lines of list items will need to watch their line breaks to avoid errant list items. Sounds good to me :-) We could always require a blank line between list items, but consider this list of one-word items: * red * blue * green Do we really want to require the author to add a blank line between each item? I don't. Nor me - I agree, compact lists like this are much best without blank lines. When list items require more than one line (in whatever tool I'm using to edit at the time) it can make sense to insert blank lines. To me, at least... -- Thomas ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown MIME type?
Aristotle Pagaltzis wrote on 2008/02/04 13:44: * Thomas Nichols [EMAIL PROTECTED] [2008-02-04 14:10]: When this came up on the list before I think there was a consensus that `text/x-markdown` is usable -- possibly with a URI to identify the Markdown syntax used. Did I understand that correctly? Yes, you did. Using a type with a subtype starting with `x-` is permissible, and in absence of a registered MIME type, the only thing that third parties can do. Note [RFCÂ 4288, section 3.4][1], though: However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both x- and x. forms is discouraged. [1]: http://tools.ietf.org/html/rfc4288#section-3.4 Regards, Yup, I remembered that -- their definition of simplified may differ from mine ;-) This from Sam Angove is informative: http://six.pairlist.net/pipermail/markdown-discuss/2007-June/000646.html Andrea Censi confirmed that [Maruku documents could be identified by profiles][] and use: text/x-markdown; profile=http://maruku.org/syntax/#ver; though there was some ensuing discussion about the legitimacy of fragment identifiers for this purpose (or at least of parsing them, instead of considering the URIs to be opaque). If we could reach consensus about mime-type / profile, we could perhaps submit them to Mozilla/Opera as recognised types to be rendered as text/plain if no helper is installed? [Maruku documents could be identified by profiles]: http://six.pairlist.net/pipermail/markdown-discuss/2007-June/000661.html -- Thomas. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Revisiting mime-types and file extensions
Michel Fortin wrote: Le 2007-06-20 à 5:51, Thomas Nichols a écrit : Having a mime type of 'text/x-markdown' and a profile URI declared by the author of the language grammar (e.g. http://maruku.org/0.5;) seems an economical solution, and would follow the pattern for [XML namespaces][xml-namespaces], Java JAXP feature URIs[jaxp-features] and [OpenID identifiers][openid] All these need a unique identifier to work anywhere, ensuring that authors will create the unique identifier. Not the case with Markdown: anyone can create his own version without creating a corresponding unique identifier. If a downstream developer, someone else than the original author, needs an identifier and decide to create one, nothing ensure others will use the same identifier; and here goes the unique part of the identifier. Yup, this is true - so maybe it would be good for the author of any new Markdown-derivative syntax to specify an identifying URI (as you have done below)? It most certainly should not be the _document_ authors who create such URIs, and if it is a downstream _processor_ author, for example Andrea Censi with Maruku, then he could define a new URI - perhaps http://maruku.org/syntax#0.5 - and declare that it is a superset of the specs http://michelf.com/ref/markdown-extra#v1.1 http://daringfireball.net/projects/markdown/syntax#1.0.1 (or whatever Mr Gruber would care to choose as a profile identifier). Beside, what does the identifier corresponds to anyway? A specific implementation? A particular syntax? One version of that implementation or that syntax or all of them? I can't really figure out right now: how many unique identifiers are needed and how are each going to be used? A great reason for having formal language grammars! :-) In the absence of such grammars, though, we have the syntax supported by Markdown.pl 1.01 or the syntax as specified at http://web.archive.org/web/20060530023711/http://daringfireball.net/projects/markdown/syntax (in other words, John Gruber's syntax definition as at 30 May 2006). I'm guessing that a new URI will typically be issued for a new version of a spec, introducing features that are not handled (or - gasp - are handled differently) in earlier versions. As a CMS developer, when processing a document, I can examine the mime-type (text/x-markdown) and look for a profile URI. I can then select an appropriate processor for this profile, or warn the user if it is not a profile that I recognize. All that is needed to get this to work is for downstream developers of Markdown-derivative processors to define their own URI and to declare which other profiles are supported. I'd guess that in order to be considered a Markdown processor at all, John Gruber's original profile should always be supported. Any suggested changes to this? Michel, would you care to propose a URI for Markdown Extra, should anyone decide they'd like to use one? I'm still not sure using URLs for this is worthy, but if someone wants a reference URL for Markdown Extra, I'd suggest using this: http://michelf.com/ref/markdown-extra I've put a small explanatory document at this address. If you need versioning, here is what I suggest: http://michelf.com/ref/markdown-extra#v1.0 http://michelf.com/ref/markdown-extra#v1.1 These are the two points at which PHP Markdown Extra changed its syntax specification (besides beta versions) to accomodate new features. Excellent, thank you very much; using fragment identifiers for versions works for me. Andrea, would you be happy with http://maruku.org/syntax http://maruku.org/syntax#0.5 as profiles? And John, as the instigator of this dance, would you care to suggest a canonical profile URI? Or should it be just http://daringfireball.net/projects/markdown/syntax http://daringfireball.net/projects/markdown/syntax#1.0.1 ? As per the XML namespaces spec, we'll be relying upon exact string matching to identify profiles. Thanks to all who've worked on this. Regards, Thomas. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Revisiting mime-types and file extensions
Andrea Censi wrote: Excellent, thank you very much; using fragment identifiers for versions works for me. Andrea, would you be happy with http://maruku.org/syntax http://maruku.org/syntax#0.5 as profiles? OK for me. It's better with a final slash: http://maruku.org/syntax/#ver so that it's easier to serve a document (rubyforge.org does not support multiviews). Ok -- so your primary profile would be http://maruku.org/syntax/ and the current spec would have a profile of http://maruku.org/syntax/#0.5 is that correct? This would allow us to chop the fragment identifier -- '#major.minor' -- from the end of a profile, and match it against /\#(|v|ver)\d+\.\d+$/ or similar. As a Ruby regex (I don't know Perl/PHP regex, it might differ) this should I think give $2 as major and $3 as minor version for the URIs we've discussed here. I'm assuming that version IDs will have a standard major.minor.bugfix format and that we can disregard the third element as irrelevant to the specification. If we ever got energetic enough to implement all of this, we could then create documents and mark them with mime-type of text/x-markdown;profile=http://maruku.org/syntax/#0.5 and then when we later come to render them (perhaps on a different system if the database has been dumped and reloaded) we'd be able to decide whether this document can be safely rendered, or whether the user should be warned that she needs to 'sudo gem install maruku' or perhaps 'sudo gem update maruku'. We could also allow her to specify 'vanilla Markdown 1.0 as the syntax, in which case it could still be rendered on systems which have only BlueCloth available. This is enough for us to work with for now. For a 'standard' profile, we'll be guided by John Gruber -- or if he has no objections, we'll use http://daringfireball.net/projects/markdown/syntax http://daringfireball.net/projects/markdown/syntax#1.0 Best regards, Thomas. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Revisiting mime-types and file extensions
Phil Mocek wrote: On Thu, Jun 21, 2007 at 02:45:08PM +0100, Thomas Nichols wrote: Ok -- so your primary profile would be http://maruku.org/syntax/ and the current spec would have a profile of http://maruku.org/syntax/#0.5 is that correct? This would allow us to chop the fragment identifier -- '#major.minor' -- from the end of a profile, and match it against /\#(|v|ver)\d+\.\d+$/ or similar. [snip] If we ever got energetic enough to implement all of this, we could then create documents and mark them with mime-type of text/x-markdown;profile=http://maruku.org/syntax/#0.5 Can anyone confirm that having the HTML fragment identifier formatted as Thomas proposes is valid? Both this [W3C design issue paper][1] and [Wikipedia article][2] suggest otherwise, but I'm not sufficiently familiar with this to say for certain. [1]: http://www.w3.org/DesignIssues/Fragment.html [2]: http://en.wikipedia.org/wiki/Fragment_identifier I'm not sure whether [1] implies that 1.0 is an invalid fragment for HTML documents, for example: For HTML, the fragment ID is an SGML ID of an element within the HTML object. For XML, if it is just a word, then it is the XML ID of an element in the document Since an XML fragment could contain any valid XPointer expression, I don't think there'd be any problem with 1.0 - and [RFC3986] reads: The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. I just noticed the syntax of the URI for this RFC (see below) -- does that look conclusive? Best regards, Thomas. [RFC3986]: http://tools.ietf.org/html/rfc3986#section-3.5 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Revisiting mime-types and file extensions
A. Pagaltzis wrote: * Michel Fortin [EMAIL PROTECTED] [2007-06-16 15:15]: Le 2007-06-16 à 2:57, A. Pagaltzis a écrit : * Michel Fortin [EMAIL PROTECTED] [2007-06-16 01:30]: Specifically, what happens if I change the page URL to PHP Markdown Extra some day? Nothing. Just because people are accustomed to HTTP URIs being derenferencable to some actual page or other resource doesn’t mean they actually have to be. Yes, but there is no point in using a URI in this case. It’s a globally unique identifier. FWIW, the [Ruby MIME::Type library][ruby-mime-type] chooses URIs as GUIDs. This seems a sane decision to me, since the domain registration process guarantees uniqueness without any of the submission/discussion/approval steps required for a more formal approval. Having a mime type of 'text/x-markdown' and a profile URI declared by the author of the language grammar (e.g. http://maruku.org/0.5;) seems an economical solution, and would follow the pattern for [XML namespaces][xml-namespaces], Java JAXP feature URIs[jaxp-features] and [OpenID identifiers][openid] It would allow creation of a Markdown Extra Plus grammar, say, even if the current project leads are unavailable to confirm whether 'text/x-markdown-extra-plus' has already been allocated. I do not expect any resource to be necessarily _available_ at that URI; if one can be retrieved, I'd expect it to be an explanatory text/html document. Would there be any objections to our implementing such a scheme (internally to Railfrog)? We're considering using http://daringfireball.net/projects/markdown/?version=1.0 - documents can be processed by either BlueCloth or Maruku http://maruku.org/?version=0.5 - documents can be processed by Maruku The version number could be used in future to handle changes to the grammar. Any suggested changes to this? Michel, would you care to propose a URI for Markdown Extra, should anyone decide they'd like to use one? Regards, Thomas. [ruby-mime-type]: http://mime-types.rubyforge.org/classes/MIME/Type.html [xml-namespaces]: http://www.w3.org/TR/REC-xml-names/#iri-use [jaxp-features]: http://xml.apache.org/xalan-j/features.html [openid]: http://openid.net/ [railfrog]: http://www.railfrog.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Revisiting mime-types and file extensions
Sam Angove wrote: On 6/15/07, Thomas Nichols [EMAIL PROTECTED] wrote: Using the experimental types indicated by 'x.' and 'x-' might also be a possibility in the short term, but is not recommended; a properly registered mime type in the main tree would provide a clear standardisation. Is this important enough to anyone else to warrant an attempt to register a name? Or should we just create a solution specific to our own problem domain? I expect that submitting something acceptable to the IETF standards track would be rather a lot of work and probably fail. The lack of clear standardisation is an issue regardless, and would have to be resolved *before* submission. Are you referring here to lack of _Markdown_ standardisation? Markdown != Markdown Extra != Maruku and so on? If so, I was thinking these might become subtypes - .markdown.basic, .markdown.maruku etc. But if a full EBNF grammar must be defined for each before standardisation can begin then this is evidently a non-starter. My assumption was that, as for (say) text/rtf, the mime type would identify a _family_ of specifications, with internal version numbers to distinguish between them. For the vendor tree, the guidelines do qualify well-known producer, IANA-approved designation of the producer's name, etc. It's not clear that `vnd.markdown` is appropriate. Even if it is, what would it *mean*? This bothered me too -- and 'vnd.gruber.*' might conflict with some other 'gruber'. Perhaps 'vnd.daring-fireball.markdown' might work - but I prefer your suggestion below. Right now we really have `text/prs.gruber.markdown`, `text/prs.fortin.php-markdown-extra` etc. etc. Markdown implementations generally implement something close to the former, but there are ambiguous edge-cases so who knows for sure? Proposals for a normative grammar went nowhere. Ok -- well I am most certainly not about to open _that_ debate ;-) `text/x-markdown` seems a reasonable media-type to encompass the whole murky, underspecified lot of them. Specific extensions/implementations could be indicated with an optional parameter, like: text/x-markdown; profile=http://www.michelf.com/projects/php-markdown/extra/; That seems better than requiring a separate media type for every extension. YMMV. This looks a workable option for us (and is in fact what we were doing last time we played with this). The 'profile' idea is also interesting -- though for consistency with other mime-types would this be the optimal syntax? With embedded space/newline and semi-colon? Looking at the [Apache mime types][apache-mime-example], for example, they all seem to be just alphanumerics, hyphens and slashes - or are you suggesting this as an analogue of a Content-Type string, where I might have CONTENT=text/html; charset=ISO-8859-1 ? I'm not at all sure how we'd handle that, but it might make a straightforward way to distinguish Maruku-flavoured-Markdown from, say, BlueCloth-flavoured-Markdown. In which case... What profile URIs would people suggest? How about: * http://daringfireball.net/projects/markdown/ * http://maruku.rubyforge.org/ ? Or should those have major/minor version numbers appended: * http://daringfireball.net/projects/markdown/1.0 * http://maruku.rubyforge.org/0.5 ? If the profile is not sufficient precisely to identify the supported language syntax, I'm not sure it would have much practical value for us. OTOH, if by looking at the profile string we could identify exactly which processor was required then we can build a more flexible tool. As an aside, I think the reStructuredText case is one to avoid repeating: it has an IANA registration as `text/prs.fallenstein.rst`, but its highest-profile [user][1] prefers `text/x-rst`. [1]: http://www.python.org/dev/peps/pep-0012/ Very interesting, thank you. If text/x-markdown is an acceptable compromise, we'll implement this. Thanks also to all who suggested file extensions -- all but 'md' seem unambiguous; it appears that 'md' has some [other uses][md-associations], including one for Windows Media Player. If we save a document to the filesystem we'll probably use .markdown as the extension. Thomas. [apache-mime-example]: http://unhinfo.unh.edu/NIS/Courses/Plug-ins/mime-types.html [md-associations]: http://filext.com/file-extension/md ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Revisiting mime-types and file extensions
Hi, I'm in the process of adding support for Markdown to a minimal CMS in Rails, [Railfrog][railfrog], which uses mime types to select appropriate processing. I have had a look through the archives but have not been able to see that a consensus has emerged as to what such a mime type for Markdown should look like. My reading of the RFCs suggests that it should be within the text/* media type, and it looks as though we could with impunity use our own mime type of, say, text/vnd.railfrog.markdown but this does seem most inelegant. The [registration procedures][reg] do not seem unduly long-winded, and a mime-type of text/markdown seems entirely suitable, alongside text/rtf and text/html. This would, I believe, mean 'registration in the IETF tree' -- does that seem appropriate for Markdown? The ['text' media type][texttype] looks like the right place if I have understood correctly; however, if registration at the top level appears problematic then it should be entirely feasible to register in the 'vendor' tree: * text/vnd.markdown.basic * text/vnd.markdown.maruku * etc. If I read this correctly, no consultation process is then required. Using the experimental types indicated by 'x.' and 'x-' might also be a possibility in the short term, but is not recommended; a properly registered mime type in the main tree would provide a clear standardisation. Is this important enough to anyone else to warrant an attempt to register a name? Or should we just create a solution specific to our own problem domain? In Railfrog we also allow content to be loaded from the file system, with the mime type being inferrred from the file extension. Having reviewed the archives, our current intent is to load as Markdown any files with the extensions * .markdown * .mdtext * .mdml (from [file-extensions], though not at http://www.filext.com) Any suggestions for others we should also be handling? Any comments/flames would be most welcome - and many thanks to everyone who has worked to keep Markdown so clear and simple! Thomas. [railfrog]: http://www.railfrog.com/ [reg]: http://www.mhonarc.org/~ehood/MIME/2048/rfc2048.html#2.1 [texttype]: http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html#4.1 [file-extensions]: http://www.file-extensions.org/mdml-file-extension ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
