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