* Fletcher Penney <[email protected]> [2012-11-20 16:00]: > 1. Is Gruber in or out? He made his first contribution to the list in > years to basically say that he is out.
For the purposes of this effort, this question seems irrelevant, based on several reasons. See next answer. > 2. If that is true, is everyone else willing to "move past" Markdown > and into something new. Even if it's Markdown-like, it will > probably have to use a different name, unless Gruber likes what he > sees and changes his mind on the back end. Even in that case, > I think we would all be shocked if he modified Markdown.pl to be > compliant (since it hasn't seen a change in years.) Which brings us > back to the beginning of how important is the Markdown "identity." > Would it still be Markdown if the original code is non compliant? > This is a philosophical discussion that has real-world > implications. The “Markdown Extra” model applies. Consider how many implementations support its syntax extensions – in some form! (there is no formal specification for it either after all) –, and, less widely, the MultiMarkdown extensions (same caveat applies). Gruber’s blessing was not required for these to spread. And all of these implementations implement Markdown primarily – though extensions as well. None of them are bug-for-bug compatible with Markdown.pl. They all still have a legitimate claim to the “Markdown” name – in fact Gruber’s de-lurk posting essentially sanctioned this use. If the implementations of this new standard still process documents in the spirit of Markdown.pl, I see no problem in them claiming a name that includes “Markdown”. They *are* Markdown implementations – only ones that are consistent amongst each other, and optionally with some stuff on top. Just like Markdown Extra. It won’t matter if Markdown.pl is never updated since normal users will almost never see difference between its output and that of one of these newer tools (as long as they’re not relying on “Markdown Plus” features obviously) – same as Markdown Extra. As for applications that support Markdown, few of them use Markdown.pl any more, from what I can tell. So no concern there either. > 3. Similarly, you now have to "herd cats" and convince the developers > (and users) of various implementations that it's worth the days > (weeks?) of effort it might take to bring their own code into > compliance. And at the end, what do they have to show for it? Old > documents that no longer work as expected? If you and Michel implement it I think the rest will be history. Get the GitHub, StackExchange and/or Reddit guys on board, and it’s a wrap. Make sure the needs of these biggest users are heard, whatever you do; which shouldn’t be hard since they’re all implementers too. Above all make sure the effort yields as a primary deliverable besides the standard a large test suite. That will make it irresistible to a certain cohort of implementers all by itself. Esp if it separates the tests for the formalised version of Gruber’s Markdown from those of the syntax extensions from the new standard. > 4. I don't agree with the command line switch approach that has been > discussed. If something like this is going to work, I think > everyone needs to jump in with both feet. Keep old code around for > older documents (it doesn't stop working, after all). But trying > to maintain two separate behaviors is going to be more challenging > -- new versions should use the new behavior. IMO libraries should support both “Markdown Formalised” and “Markdown Plus” and leave it up to the application to decide which one it will offer, but applications should pick yes or not and stick with that choice: no user-facing preference. The design of the syntax extensions should attempt to be both a) natural and b) unlikely to be part of a document that isn’t explicitly using them. That way applications *can* choose to support “Markdown Plus” only, because the incompatibility with plain Markdown is minimised. > 5. The biggest danger, IMHO, is that someone puts all the time and > effort into developing a standard, but that standard has serious > conflicts with the needs of each Markdown-variant developer. For > example, I wrote MultiMarkdown to fit my needs (footnotes, tables, > LaTeX, etc). If the new standard doesn't work for me, why would > I go through the effort to standardize? Now repeat this discussion > for each variant you're trying to bring into line. Standards succeed when they formalise what is already widely supported. Standards bodies are not the place to innovate. If that is kept in mind, then this danger will be of no concern. Of course the temptation to invent features in committee is always huge. > 6. I think we all agree that standardization, in theory, is a "good > thing." The details will be critical in determining whether it works. Keep it conservative: stick to existing implicit consensus, concentrate on working out the edge cases and formalising. That is what will provide value. Anyone who is after new features can implement them independently and if a feature works out it will then be heard of anyway. > 7. As for XML, LaTeX, PDF, etc --- I would suggest standardizing the > plain text input and HTML output first. If there is a need to > standardize more than that, it can be handled down the road. These > are probably not worth worrying about now. I actually think these should be of no concern at all. I believe the nature of Markdown to be a shorthand notation for HTML, so purely as a model, the concept is obviously that all other formats flow from a HTML-to-whatever conversion in a post-processing step after Markdown has be expanded to HTML. The exception to that is support for the one feature that is likely to be added which has no direct support in HTML, precisely because of that lack of direct expressibility in HTML, namely footnotes. (Or has HTML 5 provided a solution here (and one that isn’t still evolving)?) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ Markdown-Discuss mailing list [email protected] http://six.pairlist.net/mailman/listinfo/markdown-discuss
