Re: Markdown Group - What set of goals?

Thanks for getting the ball rolling. I have a lot of questions.

To what extent are do we wish to remain true to the spirit of Markdown
as originally specified? I think Markdown is unique in that it was
intended to be read in its original form. To me, this seems less
valued now, where it remains easy for the author to read and write,
but readers are more often reading the transformed text. Popular
implementations defaulting to hard line breaks is an example of how
they are less concerned with people reading the raw text without word
wrap enabled. As more extensions are added, it also becomes more and
more like other markup formats.

I also wonder how true we wish to remain to the original syntax? I'm
guessing we do, even if slight modifications could make the syntax
more consistent or easier to read in its raw form.

Are we creating a spec for implementors, based on existing
implementations, much like HTML 5?

I hope we can provide some recommendations, but I think we need to do
a survey of existing extensions and behaviours before we can come to
any decisions.

Nathan



On 2012-11-19, at 5:59 AM, Dave Pawson <dave.pawson@gmail.com> wrote:

> On 19 November 2012 12:01, Karl Dubost <karld@opera.com> wrote:
>> What would be the Markdown group goals?
>>
>> 1. Publish a technical note with the markup as originally defined by John Gruber. (low effort)
>>
>> 2. Publish a technical note with the original markup
>>   + a cross section of what has been extended and supported elsewhere.
>>      - needs a description of each extensions
>>      - needs an interoperability report of these features
>>      - decide what is in, what is out.
>>
>> 3. Publish a technical note with the implementation details for error recovery and parsing algorithm?
>>
>> 4. Something else?
>
> Since (IMHO) the itch we want to scratch is around 2. above;
> A base spec
>   (more work here than first meets the eye)
> Something (tbd) around extensions
>    perhaps a review
>    perhaps an interop something
>    A resolution process perhaps?
>
> It seems wrong to decide what is in / out.
>  At most we could say a, b, c support this bit (perhaps with variants)
>
> I'd add scope?
>   Are we defining a syntax only?
>   transforms (to what?)
>   How to include some definition of semantics, which I think is needed.
>
>
> regards
>
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
>

Received on Tuesday, 20 November 2012 12:55:11 UTC