I use markdown, plaintext and png for all the documents I need to store long term.
Even if these formats disappear, I could trivially reimplement my own parser.
implementing a parser that tricks people into believing it parses markdown because it acts like a markdown parser in simple cases is what is trivial
it's likely that your markdown data will indeed be recoverable, but if you're generating it yourself, html is probably safer
Although I find myself wondering what this "parsing Markdown" business is even about. It's perfectly legible as plain text, that was the main design principle behind it. If the goal is to have your data accessible in future, if you can read it now, and you don't go blind, you'll be able to read it later as well.
in the controversy around the release of commonmark, john gruber made it clear that his objection to the term 'standard markdown' was specifically that what he meant by 'markdown' was a specific syntax, not a loose family of formats; see https://nitter.lanterne-rouge.info/gruber/status/50765149869...
> @twangus @s_margheim @danielpunkass They’ve done more than “formalize”. They’ve changed the syntax. New syntax, new name. That’s all I ask.
you are of course free to use any word to mean whatever you like, however much it may annoy gruber; but consider that interpreting a word in a way at variance to the rest of the conversation will leave you, unnecessarily, wondering what the conversation is even about, as in this case
if you want to discuss what people should mean when they say 'markdown', please leave me out of that discussion, and please do not attempt to use it to imply that my words meant something i did not intend
it is true that markdown degrades gracefully, as does html. but graceful degradation is not the same thing as faithful preservation of archived documents
it would of course not make sense to write a parser for a loose family of file formats, but it makes perfect sense to write a parser for a file format. as discussed extensively in the funding documents for a project we recently worked on together, this is in fact an essential activity for the faithful preservation of archived documents in that format
True.
So why did you do so?
You're well aware that in common parlance, markdown refers to any of the following incomplete list: Gruber's Markdown reference implementation (practically extinct in the wild), Git-flavored Markdown, and Commonmark. There are others, Julia's version of Markdown has some extensions and is missing at least one feature from the original. Its standard library for parsing this is called Markdown.
To write the comment you wrote, you had to pretend that you didn't know this. That's disingenuous. That kind of "what you're referring to is actually GNU/Linux" sort of nitpick is annoying.
you're well aware you waltzed into a conversation where we were using 'markdown' in precisely the way you're claiming people don't use it, then attempted to impose your own definition on the conversation, despite the fact that the existing conversation made no sense when interpreted through it. doubling down on that by attacking my integrity is contemptible behavior
you're not a contemptible person, and your better side will be ashamed of it when you look back on this conversation later
And it has the merit to be human-readable in plaintext!
perhaps you mean
indented fixed-width blocks
you can use for ascii art
or typewriter-style tables?And regardless, markdown documents -- including the table extension -- are readable without a parser.
not being able to tell which variant of a language is in use is one of the biggest problems for archival, and in particular various extensions to the microsoft word format (all made by the same company!) were what made jgc's archival work so difficult in this case
language extensions are an especially bad problem when there's no extension mechanism—because sometimes a pipe is just a pipe. but unfortunately markdown's only extension mechanism is html
Ironically, his objection was to the idea of a single and rigorous standard, you'll note that Git-flavored markdown never drew his wrath. And yet you're treating him and Swartz's implementation as if it was such a standard. Which it is not.
There is also Just Solve The File Format Problem wiki (which I have added stuff to), although it uses HTML, and does not include full specifications for all file formats (but it does for some of them), and in some cases are links to external files, but it is helpful to find information about file formats anyways.
;)
Even before the web turned into the javascript infested swamp that is now, the tags having the same visual weight as the text they enclose made it tiring to read.
Markdown's genius is in the formatting tags being almost no hindrance to readability.
People who don't know history are doomed to repeat it, but how can our future generations learn from our mistakes if all our documents are unreadable or lost by their time?
https://www.loc.gov/librarians/standards
https://www.loc.gov/preservation/digital/
https://www.loc.gov/programs/digital-collections-management/...
and that's just Library of Congress, they are hardly alone in this field