Including 'fragment identifier semantics' in MIME media type registration?
The URI specification notes that the interpretation of a fragment identifier (the part of a URI reference after a '#') depends on the media type. However, the template for media type registration doesn't have a place to document the meaning of fragment identifiers within the media type. Originally, fragment identifiers were only used within HTML documents, so the point was somewhat moot. However, now there are several specifications -- mainly from the W3C -- that use fragment identifiers more explicitly, as well as proposals for changing or adding semantics for fragment identifiers for existing media types (such as a recent proposal for a fragment identifier for plain text.) Should the registration form for media types include a statement about the semantics of fragment identifiers for that media type? Is there a consistent policy or design for 'good' fragment identifier use? Larry -- http://larry.masinter.net
+1 Regarding "good policy", I would encourage people to make fragment identifiers, where possible, refer to 'anchor' style identifiers (i.e., using an extensibility mechanism like the 'id' attribute in XML, 'name' in HTML, and so forth) rather than into the syntax and structure of the format (as XPointer allows, through use of XPath). Doing so increases the chance that a fragment identifier could be valid and useful across multiple formats. ----- Original Message ----- From: "Larry Masinter" <LMM@acm.org> To: <uri@w3.org>; <www-tag@w3.org>; <ietf-types@iana.org> Sent: Wednesday, September 04, 2002 8:57 AM Subject: Including 'fragment identifier semantics' in MIME media type registration?
The URI specification notes that the interpretation of a fragment identifier (the part of a URI reference after a '#') depends on the media type.
However, the template for media type registration doesn't have a place to document the meaning of fragment identifiers within the media type.
Originally, fragment identifiers were only used within HTML documents, so the point was somewhat moot. However, now there are several specifications -- mainly from the W3C -- that use fragment identifiers more explicitly, as well as proposals for changing or adding semantics for fragment identifiers for existing media types (such as a recent proposal for a fragment identifier for plain text.)
Should the registration form for media types include a statement about the semantics of fragment identifiers for that media type?
Is there a consistent policy or design for 'good' fragment identifier use?
Larry -- http://larry.masinter.net
On Wednesday, September 4, 2002, 5:57:01 PM, Larry wrote: LM> The URI specification notes that the interpretation LM> of a fragment identifier (the part of a URI reference LM> after a '#') depends on the media type. LM> However, the template for media type registration LM> doesn't have a place to document the meaning of LM> fragment identifiers within the media type. LM> Originally, fragment identifiers were only used within LM> HTML documents, so the point was somewhat moot. However, LM> now there are several specifications -- mainly from LM> the W3C -- that use fragment identifiers more explicitly, LM> as well as proposals for changing or adding semantics LM> for fragment identifiers for existing media types LM> (such as a recent proposal for a fragment identifier LM> for plain text.) LM> Should the registration form for media types include LM> a statement about the semantics of fragment identifiers LM> for that media type? Yes, your well presented summary above clearly indicates that the addition of such a section would be a desirable enhancement and close the lgap between media types and the URI specification. LM> Is there a consistent policy or design for 'good' LM> fragment identifier use? Previously I would have said yes; current discussions indicate that there is some disagreement, but it is being actively discussed. I hope that it will be possible, fairly soon, for the Architecture document to specify 'best practice' and 'common idiom' and to clarify, in a way that covers the majority of existing specifications, what fragment identifiers do and how best to construct them and how they may be used or their use may affect other stages of processing such as presentation. Currently, I believe that we may have to note that there are existing exceptions that have an entirely different model. Although I am hoping that by appropriate layering, we may be able to have a low level and universally applicable "syntactic" processing that says "this portion/fragment of the content has been linked to" and higher levels ('presentation', and 'semantic') that say, respectively what the effect of traversing a link including a fragment has on presentation and what effect it has on application semantics (hoping that covers the RDF case). There is some initial wording to that effect in the Architecture document, though it needs further discussion. http://www.w3.org/TR/2002/WD-webarch-20020830/#fragid -- Chris mailto:chris@w3.org
I have some questions about fragment identifiers. When the media type is determined by negotiation, how can users specify fragment identifiers in advance? I'm happy to see that the TAG is already considering this issue. If fragment identifiers are interpreted by clients, why should they be standardized as part of URIs? To me, they are not part of URIs or protocols, but they are instructions to clients. In other words, why different applications for the same media type have to agree on fragment identifiers? Cheers, Makoto
participants (4)
-
Chris Lilley -
Larry Masinter -
Mark Nottingham -
MURATA Makoto