Is there anyone would like to hold a standard organization of Markdown syntax?
sgbotsford at gmail.com
Sun May 20 08:29:26 EDT 2012
IF concensus could be reached, then many implementors would have to decide
how to support it. There is very little history of open source projects
merging, particularly when there are multiple forks of it
Mind you Posix is such a standard and it came up well after there were a
zilling dialects of Unix. (And many GNU utilities have a flag,
--posix-me-harder for compliance in the face of common usage.)
And there lies the hint:
Either command line flags, a dot rc file, or preferences for GUI
implementations that handles the feature difference. This allow people who
cling to 'the way that works' and is generally a good thing for any program
that is use as a toolchain component.
Each author could also be responsible for a conversion program to migrate
texts from their way to 'standards compliant'
The question then becomes for the authors: What's in it for them. Where
before they were the sole prince of a small principality, now they become a
cabinet member of a major state. No major feature change without concensus.
Does Flether even exchange email with the author of Pandoc?
I'm not hopeful of a merging of any of the strands happening. It's come up
before on this list, but has received no support from any of the authors
that I recall.
Sherwood of Sherwood's Forests
Sherwood's Forests -- http://Sherwoods-Forests.com
50042 Range Rd 31
Warburg, Alberta T0C 2T0
On 19 May 2012 19:00, Paul Wilson <pw6163 at gmail.com> wrote:
> > If held, the ORG need a concil to discuss standard, and a website to
> > publish standard. I think most of the author who implemented markdown
> > converter in any language could be the concil member, not only the
> > author (Because he has not been maintaining the syntax for so long
> What impact would you expect (or require) this to have on the current
> varied Markdown
> implementations? I'm not sure that creating a bureaucracy in this manner
> would help
> all that much - yes, you could perhaps evolve a standard after substantial
> but what next?
> The current implementations serve a purpose for the authors, and the fact
> that they
> are all somewhat different is a reflection of the use that the authors put
> them to. A
> new standard would either (1) be a subset of all the existing
> implementations, or (2)
> a combination of all available options.
> (1) is not going to work for those who use existing conversion tools and
> rely on the
> features that your standard doesn't support. Why should they change what
> they need
> just because a committee says so?
> (2) is, frankly, going to be a mess. Your committee would have to choose
> different syntax for very similar features, and that's going to alienate
> some of the
> development community.
> The likely outcome is (3) a supported feature list, more than minimal,
> less than the
> total. Somewhere between (1) and (2) above. And then, what about those who
> want features not on your committee's list?
> I have some sympathy with what you're trying to achieve, but I don't think
> that a
> committee (which will inherently have no power) is the answer. I'd be
> interested to
> hear other opinions though.
> "Software - secure, cheap, quick - choose any two"
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Markdown-Discuss