Revisiting mime-types and file extensions
nichols7 at googlemail.com
Mon Jun 25 12:40:51 EDT 2007
Michel Fortin wrote:
> Le 2007-06-21 à 9:45, Thomas Nichols a écrit :
>> This would allow us to chop the fragment identifier -- '#major.minor' --
>> from the end of a profile, and match it against
>> or similar.
> I thought you needed an opaque URL to identify a specific version...
> treating URLs as anything else than an opaque string or a location
> reference, by inferring extra information from it, isn't a very good
> idea in my opinion. I'd use a separate version argument on the MIME
> type if I were you, because it doesn't force anyone to follow your own
> rules when crafting their URLs.
I'm not sure what problems might arise from passing of the URI (rather
than treating it as an opaque identifier), but I'm happy to accept this
that it may cause problems in some circumstances. Does the following
logic seem reasonable?
* if a 'version="whatever"' argument is present, use this as the
version, and parse it as specified below
* otherwise, attempt to parse the URL and scan for a terminating
For maximum flexibility, any profile URI ending '1.2' or '1.2.3' could
be interpreted as a version string -- in other words, matching
In fact, since it seems common practice also to use a hyphen or
underscore rather than a period as a separator, and to insert 'beta',
'rc' etc. Into version strings, how about extending this to
I think this matches all common practice that I am aware of. Any profile
URI ending 1.2, 1-2-3, 1.2_beta7 should be matched, $1 and $2 should
give major and minor and $4 the optional 'bugfix' third element.
>> I'm assuming that version IDs will have a standard major.minor.bugfix
>> format and that we can disregard the third element as irrelevant to
>> the specification.
> I think you've just made two big and possibly flawed assumptions. Just
> have to look at the changes for Markdown 1.0.1 and it's easy to spot a
> few important ones, like these two:
[ ... snipped examples where third component of version ID affects
syntax ... ]
> These are two big changes for a x.x.1 release.
Accepted. I hope the above addrresses this.
I'd like to avoid this becoming a 'bikeshed' discussion if possible
-- do you think this is a workable proposal?
More information about the Markdown-Discuss