Stage 1 Proposal: Redesign of Image to Include Metadata

[Eliot Kimber <ekimber@contrext.com>]

Requirements:

1. Enable direct inclusion of metadata in image elements, and more generally, make <image> elements better suited to being managed as independent objects, such as from image selection dialogs in editors or in content management systems that manage images as more-or-less independent objects.
2. Provide an element that does nothing other than link to the image resource. This serves three main purposes:
	A. Decouples the logical image, reflected by its metadata and alternative text, from its various available renderings, such as different image formats of the same logical image, suitable for different delivery contexts 
	B. Provides a single, empty element that does nothing except refer to an image. This better supports tools that directly map image-referencing elements to images, such as some XML editors and some rendering systems.
	C. Allows a single logical image element to refer to multiple alternatives or variants without requiring the use of keys.

Proposal:

* Remove the reference-related attributes @href, @keyref, and @format from <image> and move them to a new subelement, <imageref>.
* Define a new base element <imageref>, which is allowed as a subelement of <image>. The <imageref> element has empty content and takes the @href, @keyref, and @format attributes, as well as all the universal attributes, including @conref and @conkeyref. The semantic of this element is that it is a reference to some form of graphic resource with the default intent being to present the referenced resource at the point of occurrence of the containing <image> element (as opposed to being a navigable hyperlink to an image presented separately).
* Define a new element, <imagelabel>, specialized from <data>. This element provides a descriptive label for the image, for example, for use in image selection dialogs or in content management systems that manage <image> elements as individual objects. As for <data> generally, the image label is not intended to be presented by default in normal deliverables. Note that the image label is different from the image alt, which is intended to be presented, either directly or at user request and is, ideally, an informationally-complete alternative to the image itself.
* Modify the content model of <image> to:

  ((%imagelabel;)?,
   (%data;)*,
   (%imageref;)+,
   (%alt;)?,
   (%longdescref;))

That is:

* zero or one <imagelabel> element
* zero or more <data> elements
* one or more <imageref> elements
* Zero or one <alt> element
* Zero or one <longdescref> element

Multiple <imageref> elements are allowed in order to enable references to alternative renderings or variants of the same logical graphic, distinguished either by selection attributes, by xml:lang, by the format of the of the referenced resource, or any combination of those or other available properties. Where the selection of a specific <imageref> element is not determined by DITA-defined means processors may use any mechanism for choosing the appropriate image to use for a given delivery. The default selection mechanism should be to choose the first <imageref> element in document order (e.g., the XPath expression "image/imageref[1]").

The default presentation behavior is that at most one of the referenced image resources will be presented directly in the deliverable to which the <image> element. Depending on the nature of the deliverable, other variants may be made available to users (for example, the initially-rendered variant may be a low-resolution version with the higher-resolution variant available on user action).

The design intent is that the <image> element represents a single logical image, binding the metadata, alternative text, and long description to the resources that are the concrete renderings of the logical image. 

For managing variant renditions of the same logical graphic,  authors can choose as matter of information management policy whether to use multiple <imageref> elements or to use a single <imageref> element with a key reference (where a key reference is always potentially resolvable to different definitions depending on how the key definitions are defined within a given use context).

Note that <alt> allows the usual inline elements so already provides for having different versions of the alt text controlled via filtering or through content reference, so there is no compelling need to allow multiple alt elements nor multiple longdescref elements.

Cheers,

E.
--
Eliot Kimber
http://contrext.com