Revisiting mime-types and file extensions

[Thomas Nichols]

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.