Re: Revisiting mime-types and file extensions

[A. Pagaltzis]

* Michel Fortin <[EMAIL PROTECTED]> [2007-06-16 01:30]:
> Specifically, what happens if I change the page URL to PHP
> Markdown Extra some day?

Nothing. Just because people are accustomed to HTTP URIs being
derenferencable to some actual page or other resource doesn’t
mean they actually have to be.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Revisiting mime-types and file extensions

[Sam Angove]

On 6/16/07, Thomas Nichols <[EMAIL PROTECTED]> wrote:


This looks a workable option for us (and is in fact what we were doing
last time we played with this). The 'profile' idea is also interesting
-- though for consistency with other mime-types would this be the
optimal syntax? With embedded space/newline and semi-colon?


The newline wasn't intentional, darned email, but yes, like Content-Type.

   content := "Content-Type" ":" type "/" subtype *(";" parameter)

I suggested the parameter because something similar is specified for
[`application/xhtml+xml` RFC][rfc3236].

[rfc3236]: http://tools.ietf.org/html/rfc3236#section-8



If the profile is not sufficient precisely to identify the supported
language syntax, I'm not sure it would have much practical value for us.


Of course, `text/x-markdown+extra` won't give you that either.

The primary advantage of a URL is that it provides a discovery
mechanism. It also makes explicit that different "profiles" are all in
the Markdown family, which a shared `x-markdown` prefix doesn't.

Anyway, Michel Fortin is probably right, and the whole scheme is too
complicated to bother with.

Never mind. :)
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Revisiting mime-types and file extensions

[Phil Mocek]

On Fri, Jun 15, 2007 at 07:29:46PM -0400, Michel Fortin wrote:
> Le 2007-06-14 à 22:45, Sam Angove a écrit :
> > `text/x-markdown` seems a reasonable media-type to encompass
> > the whole murky, underspecified lot of them. Specific
> > extensions/implementations could be indicated with an optional
> > parameter, like:
> > 
> >text/x-markdown;
> >profile="http://www.michelf.com/projects/php-markdown/extra/";
> 
> That seems complicated to me. 

Complicated, maybe.  But does it conform to an established
convention?

> Specifically, what happens if I change the page URL to PHP
> Markdown Extra some day?

You'll create many broken links, causing trouble for everyone
who has ever linked to your page.  Please don't do that.

See [W3C: "Cool URIs don't change"][1].

[1]: 

-- 
Phil Mocek
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Revisiting mime-types and file extensions

[Michel Fortin]

Le 2007-06-14 à 22:45, Sam Angove a écrit :


`text/x-markdown` seems a reasonable media-type to encompass the whole
murky, underspecified lot of them. Specific extensions/implementations
could be indicated with an optional parameter, like:

   text/x-markdown;
profile="http://www.michelf.com/projects/php-markdown/extra/";


That seems complicated to me. Specifically, what happens if I change  
the page URL to PHP Markdown Extra some day? Why not one of these  
instead:


text/x-markdown.extra
text/x-markdown+extra

?


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Revisiting mime-types and file extensions

[Thomas Nichols]

Sam Angove wrote:
> On 6/15/07, Thomas Nichols <[EMAIL PROTECTED]> wrote:
>> Using the "experimental" types indicated by 'x.' and 'x-' might also be
>> a possibility in the short term, but is not recommended; a properly
>> registered mime type in the main tree would provide a clear
>> standardisation. Is this important enough to anyone else to warrant an
>> attempt to register a name? Or should we just create a solution specific
>> to our own problem domain?
>
> I expect that submitting something acceptable to the IETF standards
> track would be rather a lot of work and probably fail. The lack of
> clear standardisation is an issue regardless, and would have to be
> resolved *before* submission.

Are you referring here to lack of _Markdown_ standardisation? Markdown
!= Markdown Extra != Maruku and so on? If so, I was thinking these might
become subtypes - .markdown.basic, .markdown.maruku etc. But if
a full EBNF grammar must be defined for each before standardisation can
begin then this is evidently a non-starter. My assumption was that, as
for (say) text/rtf, the mime type would identify a _family_ of
specifications, with internal version numbers to distinguish between them.
>
> For the vendor tree, the guidelines do qualify "well-known producer",
> "IANA-approved designation of the producer's name", etc. It's not
> clear that `vnd.markdown` is appropriate. Even if it is, what would it
> *mean*?

This bothered me too -- and 'vnd.gruber.*' might conflict with some
other 'gruber'. Perhaps 'vnd.daring-fireball.markdown' might work - but
I prefer your suggestion below.

>
> Right now we really have `text/prs.gruber.markdown`,
> `text/prs.fortin.php-markdown-extra` etc. etc. "Markdown"
> implementations generally implement something close to the former, but
> there are ambiguous edge-cases so who knows for sure? Proposals for a
> normative grammar went nowhere.

Ok -- well I am most certainly not about to open _that_ debate ;-)

>
> `text/x-markdown` seems a reasonable media-type to encompass the whole
> murky, underspecified lot of them. Specific extensions/implementations
> could be indicated with an optional parameter, like:
>
>text/x-markdown;
> profile="http://www.michelf.com/projects/php-markdown/extra/";
>
> That seems better than requiring a separate media type for every
> extension. YMMV.

This looks a workable option for us (and is in fact what we were doing
last time we played with this). The 'profile' idea is also interesting
-- though for consistency with other mime-types would this be the
optimal syntax? With embedded space/newline and semi-colon? Looking at
the [Apache mime types][apache-mime-example], for example, they all seem
to be just alphanumerics, hyphens and slashes - or are you suggesting
this as an analogue of a Content-Type string, where I might have
CONTENT="text/html; charset=ISO-8859-1"
?
I'm not at all sure how we'd handle that, but it might make a
straightforward way to distinguish Maruku-flavoured-Markdown from, say,
BlueCloth-flavoured-Markdown. In which case...

What profile URIs would people suggest? How about:

  * http://daringfireball.net/projects/markdown/
  * http://maruku.rubyforge.org/
?

Or should those have major/minor version numbers appended:

  * http://daringfireball.net/projects/markdown/1.0
  * http://maruku.rubyforge.org/0.5
?
If the profile is not sufficient precisely to identify the supported
language syntax, I'm not sure it would have much practical value for us.
OTOH, if by looking at the profile string we could identify exactly
which processor was required then we can build a more flexible tool.


>
> As an aside, I think the reStructuredText case is one to avoid
> repeating: it has an IANA registration as `text/prs.fallenstein.rst`,
> but its highest-profile [user][1] prefers `text/x-rst`.
>
> [1]: http://www.python.org/dev/peps/pep-0012/

Very interesting, thank you. If text/x-markdown is an acceptable
compromise, we'll implement this.

Thanks also to all who suggested file extensions -- all but 'md' seem
unambiguous; it appears that 'md' has some [other
uses][md-associations], including one for Windows Media Player. If we
save a document to the filesystem we'll probably use ".markdown" as the
extension.

Thomas.

[apache-mime-example]:
http://unhinfo.unh.edu/NIS/Courses/Plug-ins/mime-types.html
[md-associations]: http://filext.com/file-extension/md


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: [Blosxom-users] Blosxom + Markdown problem: randomised email links break RSS, Atom

[Michel Fortin]

Le 2007-06-15 à 3:44, Ron Hale-Evans a écrit :

If no one wants to fix (or "fix") it, it should at least be  
documented. I am a technical writer by trade and will be happy to  
document the problem if someone will point me to the documentation  
leads for both projects.


I think the fix is easy: make the "random" encoding deterministic.  
I've done it for PHP Markdown recently by adding a custom pseudo- 
random generator to replace the standard random function used by the  
algorithm. The new generator is seeded with a checksum of the email  
address; this makes it deterministic.


If someone wants to port that change to Perl, I'll be glad to help.  
Here are the relevant two lines of code from the `encodeEmailAddress`  
function of PHP Markdown:


   # Deterministic seed.
   $seed = (int)abs(crc32($addr) / strlen($addr));

   # Pseudo-random function.
   $r = ($seed * (1 + $key)) % 100;

(Note: $key is the index of the current character.)


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: [Blosxom-users] Blosxom + Markdown problem: randomised email links break RSS, Atom

[Ron Hale-Evans]

On 6/13/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:


On Jun 9, 2007, at 12:26 PM, Ron Hale-Evans wrote:

> As described here, "Markdown will... perform a bit of randomized
> decimal and hex entity-encoding to help obscure your address from
> address-harvesting spambots" on automatic email address links like
> <[EMAIL PROTECTED]>.
> ...
> I grepped the content tree for my blog. The problem posts were the
> _only_ ones that contained my address in this form. Apparently the
> random entity-encoding generated by Blosxom kept changing and causing
> these entries to reappear in my feeds.
>
> ...
>
> I can't believe no one else has experienced this problem before, but I
> can't find any previous reference to it. Does anyone have any comments
> on this problem? Is it likely to be fixed?

Since you cross-posted, it's not clear to me who you are expecting to
"fix" this.  It doesn't seem like a problem in Blosxom, though.  The
content of your posts is changing, readers see that and mark the
changed content as new again.  I can see that from your point of view
this is a mis-feature of markdown, but it doesn't seem that blosxom
could do anything to help you here.


First, I'm glad you answered, Kevin. Thank you. Second, it strikes me
that this is a Blosxom/Markdown incompatibility, and therefore a
problem for _both_ the Blosxom and Markdown developer communities. If
no one wants to fix (or "fix") it, it should at least be documented. I
am a technical writer by trade and will be happy to document the
problem if someone will point me to the documentation leads for both
projects.

Ron H-E

--
   Ron Hale-Evans ... [EMAIL PROTECTED] ... http://ron.ludism.org/
Mind Performance Hacks book: http://www.oreilly.com/catalog/mindperfhks/
   Center for Ludic Synergy: http://www.ludism.org/
(revilous life proving aye the death of ronaldses when winpower wine has
   bucked the kick on poor won man)
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss