FYI: Fragments and MIME/Types

http://www.w3.org/DesignIssues/Fragment.html

   
    Tim Berners-Lee
    Date: April, 1997
    Status: personal view, but believed to be my best expression of the
    underlying architecture for W3C development. Editing status: Good
    enough fo discussion.
    
   [1]Up to Design Issues
   
  Axioms of Web Architecture: 1a
     _________________________________________________________________
   
                         Fragment Identifiers on URIs
                                       
   The fragment identifier is a string at the end of a URI which
   identifies, within a Web document, a part or view to which one refers.
   For example in the object
        http://foo/bar#frag

   the string "frag" is the fragment identifier.
   
   (Depending on where you look, the URI is considered to include the
   fragment identifier, or to have the fragment identifier appended to
   it.  This is important for the BNF, but in practice you will find
   people using the terms URI and URL loosely to things which do or do
   not include a possible fragment identifier. Formally, the URI DOES
   include the fragment ID)
   
   In practice, you can divide the processing which occurs when following
   a link using HTTP into three steps:
   
    1. The client figures out which server to contact by parsing part of
       the URL, and sends the URL as a request to the server;
    2. The server figures out which object is referred to by parsing the
       rest of the URL, and returns some rendition of it to the client;
    3. The client presents all or part of the object to the user
       
   The last part typically involves finding some software class which can
   handle the given MIME type, and passing it the data stream.  At the
   same time, the fragment identifier is passed as an extra function.
   
   For HTML, the fragment ID is and SGML ID of an element within the HTML
   object.
   
    Axiom
    
   The significance of the fragment identifier is a function of the MIME
   type of the object
   
   This means that the fragment id is opaque for the rest of the client
   code.  The HTTP engine cannot make any assumptions about it.  The
   server is not even given it.
   
   It also means that for any new data type one can be creative about
   using the fragment ID in a relevant way. For example, for a 3D object
   the fragment ID  could give a viewport. For a music object, the
   Fragment ID could give a  section in time, or a set of parts, or it
   could include a suggested tempo.  For future versions of HTML, the
   fragment ID could be made more powerful to include a range or "ladder"
   reference to a part or parts of the SGML element tree by position. A
   very useful fragment ID for plain text would allow ranges to be quoted
   by line and character number
   
   These things are all decisions made when the MIME type is defined.
   Therefore,
   
   The fragment ID spec for a new MIME type should  be part of the MIME
   type registration process.
   
   Different MIME types then can have different fragment ID
   specifications. When HTTP for example negotiates between different
   content types, it is clearly useful for those types to have a
   consistent (hopefully identical) fragment ID syntax and semantics.
   
  Fragment IDs and Content negotiation
  
   If content negotiation occurs across types which do NOT share a
   fragment ID specification, then rigidly there has been an error. In
   practice, HTML is the only type (1997) which allows fragment IDs
   anyway, and other types ignore it. Also, as falling back from a
   pointer to a specific view to a pointer to the whole document has been
   considered effective fallback procedure, so no harm has been done.
   
   In the future, metadata returned or warnings returned should indicate
   to the client that this could be a problem. Also, in new access
   protocols, the fragment ID requested could be shipped to the server as
   a hint, which would allow the server and client to negotiate and if
   successful arrange for the fragment ID to be converted to a suitable
   equivalent value for an alternative MIME type.
   
  User awareness of the form of a reference
  
   Clearly when a fragment ID is generated and associated with a URI
   which is generic in any way (language, version, etc as well as
   content-type), then there is a possible failure of the fragment-id
   refers to something which is not defined in any specific instance.  It
   would be appropriate for a client, when generating a link (or
   bookmark, etc) to provide the user with a choice of
     * A bookmark to the whole living document, or
     * A bookmark to a specific part of a "dead" version;
     * Intermediate combinations.
       
   As both these options are meaningful and useful, they will have to
   surface at the user interface level.
     _________________________________________________________________
   
   [2]Next: Links and the law
   
   [3]Up to Design Issues
   
   $Id: Fragment.html,v 1.6 1998/03/04 17:24:58 timbl Exp $

References

   1. http://www.w3.org/DesignIssues/Overview.html
   2. http://www.w3.org/DesignIssues/LinkLaw.html
   3. http://www.w3.org/DesignIssues/Overview.html



_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Friday, 15 October 1999 10:46:07 UTC