(7) Browsers and Resources

• Web browsers retrieve resources and render them
  • HTTP can transfer any kind of resource (binary resources must be transfer encoded)
  • resource types cannot (and should not) be inferred from the URI
• HTTP combines data transfer, transfer management, and metadata
  • basic information about a resource (modification date)
  • information describing the resource's type (media type) and content (language)
  • [@http-conneg] can be used to request a specific resource variant
• The resource type received may or may not be supported by the browser
  • built-in support is provided for the core Web resource types (HTML, GIF, JPEG)
  • plug-in support is an add-on to the browser for popular types (PDF, Flash)
  • external applications are standalone applications invoked by the browser

(8) Firefox Media Type Handling

(9) Media Type Control in Browsers

• In practice, media type control is less than perfect
  • getting control over media types means getting control over your computer
  • applications are rarely written in a perfectly well-designed way
• XML is handled very poorly by Firefox
  • rendering XML is unbelievably slow (and very primitive)
  • if the XML has errors (real or imagined by Firefox), there is no way to get to it
  • helper applications can be registered, but this is ignored by Firefox
• Competing application suites hijack as many media types as possible
  • QuickTime and Windows Media Player support the same media types
  • installing or updating these packages often changes many media type settings

(11) Content Types

• MIME splits the world of resource types into Content Types and Subtypes
  • Content types are the main classification of a resource type
  • Subtypes [Subtypes (1)] qualify the format and encoding used for the content
• Content types classify the world of resource type into 8 areas
  • audio for media types representing exclusively audio signals
  • image for any media type representing two-dimensional images
  • message for resources representing e-mail messages
  • model for complex representations of physical objects (very unpopular)
  • multipart for MIME entities containing multiple individual MIME-tagged resources
  • text for mainly textual material (e.g., HTML is considered to be text)
  • video for media types combining moving pictures with audio
  • application for any resource which cannot by classified anywhere else
  • (example is only used for media type examples, not for real-world resources)

(12) Subtypes

• Within each content type, many different data formats are in use
  • content types only allow a broad classification
  • subtypes allow the identification of a specific data format of a resource
• Subtypes are expected to be registered [Media Type Registration (1)] with the IANA [http://www.iana.org/]
  • unregistered subtypes can be used but must have a x- prefix
• Additional qualifiers can be used to be more specific
  • text/plain is the media type for plain text files
  • plain text files have additional properties such as character encoding and language
  • text/plain can be further qualified to text/plain; charset=iso-8859-1
  • not all qualifications are available as media type (e.g., language is not addressed)

(13) What is XML?

• XML can be regarded from various point of view
  • XHTML is (almost) identical to HTML and should be regarded as text
  • configuration files are data for some program and should be regarded as application
  • XML schemas can be mixes of these two extreme cases
• RFC 3023 [http://tools.ietf.org/html/rfc3023] registers a set of XML-related media types
  • application/xml for generic XML usage (data oriented XML)
  • text/xml for textual XML usage (document oriented XML)
  • application/xml-dtd for DTDs (which are not XML documents)
  • application/xslt+xml (proposed) for XSLT stylesheets (text/css is defined by RFC 2318 [http://tools.ietf.org/html/rfc2318])
  • image/svg+xml (proposed) for vector graphics using Scalable Vector Graphics (SVG)
  • application/xhtml+xml is defined by RFC 3236 [http://tools.ietf.org/html/rfc3236]
  • … and a number of other suggestions for future XML media types

(14) Media Type Registration

• Media types need to be registered together with a documentation
  • this makes sense if it is assumed that registered types should be openly accessible
  • this becomes complicated if the types are proprietary and not publicly documented
• It makes sense to register types even if they are not publicly documented
  • if a Word document is sent by e-mail it should be opened by the Word application
  • IANA registers vnd. prefixed subtypes with less requirements than regular types
  • vendor specific types are often undocumented and may change significantly over time
• Using well-defined types makes handling resources more stable
  • the IANA registry contains hundreds of types (most of them application types)
  • when designing applications dealing with various content types, use media types as the foundation

(15) application/msword Media Type

SECURITY CONSIDERATIONS:
None known.


PUBLISHED SPECIFICATION:

Specification by example:

   From any microsoft word application select "Save As..." from the
   "File" menu.  Enter a filename, make sure that "Normal" is specified
   for the file type, and click "Save".

Company Contact:

   Microsoft Inc.

   16011 NE 36th Way
   Box 97017
   Redmond WA, 98073-9717

(27) Identification of Resource Fragments

• URIs identify a resource (based on a scheme and a scheme-specific part)
  • URIs do not necessarily identify a specific representation of a resource
  • any representation-specific operation needs to look at the resource type
• Fragment identifiers can be used to identify a part of a resource
  • http://dret.net/netdret/publications#wil02h [http://dret.net/netdret/publications#wil02h]
  • fragments are a client side concept (the HTTP GET requests the complete resource)
  • if the client supports fragment handling, the identifier is interpreted
• Fragment identifiers and content negotiation have a problematic relationship
  • keeping fragment identifiers stable across resource variants may be hard
  • nothing in the fragment identifier associates it with a specific resource variant

(28) HTML Fragment Identifiers

• HTML allows to address named/identified elements in the HTML document
  • the first HTML versions required named <a name="frag-id">incoming anchors</a>
  • newer HTML versions allow <p id="frag-id">every element to have an id</p>
  • browsers support both ways, but the id variant should be preferred
• Only named/identified fragments can be identified
  • 99.99% of all page authors do not routinely add identifications
  • tools may be smarter and take over that task (e.g., Movable Type identifies all relevant elements)
  • for most pages on the Web this means users cannot link to most elements in them
• Keeping fragment identifiers stable should be a goal of Web authors
  • identify the key fragments (and maybe provide a better UI than view source)
  • never change identifiers once they have been assigned

(29) XML Fragment Identifiers

• XPointer is the language which defines XML fragment identifiers
  • XPointer's history and success is even worse than XLink's
  • the interesting part was never finished, the easier parts have been finalized
• XPointer supports HTML's approach of identified elements
  • if there is simply a name after the #, it is a shorthand and treated like in HTML
  • … almost, actually, because IDs in XML are a bit more complicated (xml:id or schema-defined)
• XPointer allows child sequences to navigate the document tree
  • …#element(/1/2) or …#element(intro/3/1)
  • the nice aspect is that elements without an explicit identification can be identified
  • the risky part is that any changes in the document structure may break the XPointer
• XPointer in all its glory (W3C working draft December 2002 …)
  • an extension of XPath inheriting all the interesting features of XPath
  • adds the concept of range locations between to XPath-identified point locations

(31) Know Your Resources

• Handling Web resources and technologies requires a common vocabulary
• Media types are a useful vocabulary for identifying resource types
• Fragment identifiers add some complexity, in particular for resource variants