Graphics have traditionally just been links which happen to have a picture file at the end rather than another piece of text. They can therefore be implemented in any way supported by the XLink and XPointer specifications (see earlier question), including using similar syntax to existing HTML images. They can also be referenced using XML's built-in
ENTITY mechanism in a similar way to standard SGML, as external unparsed
The linking specifications, however, give you much better control over the traversal and activation of links, so an author can specify, for example, whether or not to have an image appear when the page is loaded, or on a click from the user, or in a separate window, without having to resort to scripting.
XML itself doesn't predict or restrict graphic file formats: GIF, JPG, TIFF, PNG, CGM, and SVG at a minimum would seem to make sense; however, vector formats are normally preferred for non-photographic images.
Using entities for images
You cannot embed a raw graphics file (or any other binary [non-text] data) directly into an XML file because any bytes happening to resemble markup would get misinterpreted: you must refer to it by linking (see below). It would, however, in theory be possible to include a text-encoded transformation of a binary file as a
CDATA marked section, using something like UUencode with the markup characters
> removed from the map so that they could not
occur and be misinterpreted, or even simple hexadecimal encoding as used in PostScript. For vector graphics, however, the solution is to use SVG (see below).
Bob DuCharme adds: All the data in an XML document entity must be parseable XML. You can define an external entity as either a parsed entity (parseable XML) or an unparsed entity (anything else). Unparsed entities can be used for picture files, sound files, movie files, or whatever you like. They can only be referenced from within a document as the value of an attribute (much like a bitmap picture on an HTML Web page is the value of the
and not part of the actual document. In an XML document, this attribute must be declared to be of type
ENTITY, and the entity's declaration must specify a declared
NOTATION, because if the entity isn't XML, the XML processor needs to know what it is. For example, in the following document, the
colliepic entity is declared to have a JPEG notation, and it's used as the value of the empty dog element's
<!DOCTYPE dog [
<!NOTATION JPEG SYSTEM "Joint Photographic Experts Group">
<!ENTITY colliepic SYSTEM "lassie.jpg" NDATA JPEG>
<!ELEMENT dog EMPTY>
<!ATTLIST dog picfile ENTITY #REQUIRED>
The XLink and XPointer linking specifications describe other ways to point to a non-XML file such as a graphic. These offer more sophisticated control over the external entity's position, handling, and appearance within the XML document.
Peter Murray-Rust writes: GIFs and JPEGs cater for bitmaps (pixel representations of images). Vector graphics (scalable) are being addressed in the W3C's graphics activity as SVG (see http://www.w3.org/Graphics/SVG). [With the specification now virtually complete,] it will be possible to transmit the graphical representation as vectors directly within the XML file. For many graphics objects this will mean greatly decreased download time and scaling
without loss of detail.
Max Dunn writes: SVG has really taken off recently, and is quite an XML success story [...] there are already nearly conformant implementations. We recently started an SVG FAQ at http://www.siliconpublishing.org/svgfaq/ which we are planning to move to http://www.svgfaq.com/.
XSLT can be used to generate SVG from XML; details are at http://www.siliconpublishing.org/svgfaq/XSLT.asp (be careful to use XSLT, not Microsoft's WD-xsl). Documents can also interact with SVG images (see http://www.xml.com/pub/a/2000/03/22/style/index.html).