Revisiting mime-types and file extensions

[Thomas Nichols]

Phil Mocek wrote:

> On Thu, Jun 21, 2007 at 02:45:08PM +0100, Thomas Nichols wrote:

>   

>> Ok -- so your primary profile would be

>>

>> http://maruku.org/syntax/

>>

>> and the current spec would have a profile of

>>

>> http://maruku.org/syntax/#0.5

>>

>> is that correct?

>>

>> This would allow us to chop the fragment identifier --

>> '#major.minor' -- from the end of a profile, and match it

>> against

>>

>> /\#(|v|ver)\d+\.\d+$/

>>

>> or similar.

>>     

> [snip]

>   

>> If we ever got energetic enough to implement all of this, we

>> could then create documents and mark them with mime-type of

>> text/x-markdown;profile=http://maruku.org/syntax/#0.5

>>     

>

> Can anyone confirm that having the HTML fragment identifier

> formatted as Thomas proposes is valid?  Both this [W3C design

> issue paper][1] and [Wikipedia article][2] suggest otherwise, but

> I'm not sufficiently familiar with this to say for certain.

>

> [1]: <http://www.w3.org/DesignIssues/Fragment.html>

> [2]: <http://en.wikipedia.org/wiki/Fragment_identifier>

>

>   


I'm not sure whether [1] implies that "1.0" is an invalid fragment for
HTML documents, for example:   
"For HTML, the fragment ID is an SGML ID of an element within the HTML
object. For XML, if it is just a word, then it is the XML ID of an
element in the document"

Since an XML fragment could contain any valid XPointer expression, I
don't think there'd be any problem with "1.0" - and [RFC3986] reads:

"The semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the primary
resource.  The fragment's format and resolution is therefore dependent
on the media type [RFC2046] of a potentially retrieved representation,
even though such a retrieval is only performed if the URI is
dereferenced.  If no such representation exists, then the semantics of
the fragment are considered unknown and are effectively unconstrained. "

I just noticed the syntax of the URI for this RFC (see below) -- does
that look conclusive?

Best regards,
Thomas.

[RFC3986]: http://tools.ietf.org/html/rfc3986#section-3.5