Revisiting mime-types and file extensions
nichols7 at googlemail.com
Thu Jun 21 15:04:54 EDT 2007
Phil Mocek wrote:
> On Thu, Jun 21, 2007 at 02:45:08PM +0100, Thomas Nichols wrote:
>> Ok -- so your primary profile would be
>> and the current spec would have a profile of
>> is that correct?
>> This would allow us to chop the fragment identifier --
>> '#major.minor' -- from the end of a profile, and match it
>> or similar.
>> If we ever got energetic enough to implement all of this, we
>> could then create documents and mark them with mime-type of
> Can anyone confirm that having the HTML fragment identifier
> formatted as Thomas proposes is valid? Both this [W3C design
> issue paper] and [Wikipedia article] suggest otherwise, but
> I'm not sufficiently familiar with this to say for certain.
> : <http://www.w3.org/DesignIssues/Fragment.html>
> : <http://en.wikipedia.org/wiki/Fragment_identifier>
I'm not sure whether  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?
More information about the Markdown-Discuss