NOTE-HGML-19980619
NOTE-HGML-19980619
W3C Note 19-June-1998
Authors
Mike Evans: <mike.evans@jack.see.plym.ac.uk>, PRP (UK)
Steven Furnell: <stevef@jack.see. plym.ac.uk>, PRP (UK)
Andy Phippen: <andyp@jack.see. plym.ac.uk>, PRP (UK)
Paul Reynolds: <prof.reynolds@iee.org>, PRP (UK)
Neil Lilly: <neil.lilly@orange.co.uk>, Orange PCSL
John Hammac: <john.hammac@europe.simoco.com>, formally of Orange PCS PLC
Copyright 1997/1998 Orange PCSL All rights reserved
This document is a NOTE made available by the W3 Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has had any editorial control in it preparation, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by the NOTE.
This document makes public the Orange - PRP(UK) Hyper Graphics Markup Language (HGML) which has been in trials with the GSM/DCS1800 Cellular Radio system in the UK since July 1997. This public submission has been prompted by the NOTE on PGML, http://www.w3c.org/TR/1988/NOTE-PGML-19980410. We believe that there is synergy between PGML and HGML that is worthy of analysis.
Mobile access to the World Wide Web (WWW) is now technically feasible via cellular communications equipment and other wireless technologies. However, the usability of the resulting service is limited by the fact that much web content is represented in graphical form, which requires significant bandwidth and impedes downloading over the wireless medium.
This document presents the conceptual design and basic specification for a Hyper Graphics Markup Language (HGML), providing a graphically-oriented alternative to HTML specifically designed for use in wireless contexts. HGML is highly optimised for use in conjunction with narrow-bandwidth channels between client and server. It offers three key features that enable it to reduce / replace the use of conventional bitmap images in WWW pages : namely drawing primitives, pre-stored image themes and image manipulation.
The implementation of and findings from a prototype implementation are described, indicating that the HGML approach can deliver dramatic savings on both overall file size and download time when contrasted with a traditional HTML approach.
The document concludes that a full implementation of HGML would offer a number of practical benefits to mobile web users.
Web documents are formatted using the Hyper Text Mark-up Language (HTML). A Web browser, on receipt of a HTML document, interprets the HTML commands in order to format the text correctly. Web pages currently contain text, hyperlinks, images, audio and/or video files (enabling multimedia documents).
Although the textual data of Web pages is generally compact, graphics data can considerably increase download times. The speed of downloading of graphics Web pages is particularly problematic in the case of mobile or remote data links (e.g. cellular radio data link) and small Internet appliances (e.g. PDAs, handheld / palm-sized PCs).
HGML allows graphics rich documents to be downloaded using low levels of bandwidth. This system uses tags to call pre-defined locally stored graphic images, drawing primitives and image manipulators.
Cellular data communications technologies, such as GSM, provide dedicated connections between WWW clients and servers (using basic TCP/IP), and, such, decreases in throughput due to multi-user demands are no longer encountered. Even with the limited throughputs of mobile telephony, achieving only 9.6 kbps (dedicated to a single user), access times can be decreased. Through the utilisation of a novel approach to the storage and transmission of Web pages, the restrictions of cellular technology should be overcome, hence the creation of the Hyper Graphics Mark-up Language.
The following pages of this NOTE detail the HGML language and the development approach taken in a prototype implementation.
The document presents a definition of the HGML
concept, including general features and a formal specification of the markup language.
This is followed by details of an operational trial undertaken using a prototype
implementation of HGML using a suitably enabled browser. Conclusions are drawn in light of
the results obtained.
The HGML specification encompasses functionality in three key areas :
These aspects will now be examined in more detail,
followed by consideration of the main benefits and limitations that are perceived in the
concept.
This concept is designed to allow images to be downloaded and displayed faster than is currently possible using standard HTML over wireless. The idea is to reduce / replace large bitmap images with vector-based equivalents, drawn using a defined set of HTML-like tags relating to graphical primitives. These primitives include geometrical constructs such as line, circle, square, polygon, etc. (see table 1 for a complete list). Image elements are then drawn on an individual basis using command tags such as the following :
<ellipse coords="0,0,50,30", style="dotted", color=orange, fill=yellow, psize="2">
where
ellipse defines the name of the primitive to be drawn by the browser;
coords specify the co-ordinates of the primitive
style represents the style in which the primitive is to be drawn (dotted line, standard line, etc.)
color defines the outline colour in which the primitive is to be drawn
fill defines the fill colour of the primitive
psize represents the thickness of the outline of the primitive
The HGML-enabled browser, upon receiving this command, would draw the element (in this case an ellipse) at the co-ordinates indicated, using the specified style and colours. Using this method, relatively complex graphics can be constructed using few commands, enabling the resulting composite image to be downloaded faster than normal inline images.
The approach is further optimised by the inclusion of certain image-manipulation functions, allowing existing image elements to be duplicated, mirrored, rotated etc. to further reduce the need for data download if the same or similar images are required at multiple locations on the page. These features also offer the opportunity of (albeit primitive) animation features: i.e. by allowing a continuous stream of HGML manipulation tags to be sent to a client, images can be controlled by the server in real-time.
Vector-based graphics alone are limited in that they cannot provide an adequate substitute for the photo-realistic bitmaps (or other complex images) that are typically seen on the web. Whilst vector graphics commands could conceivably be used to build up such images, the resultant file-size would be likely to exceed the bit-mapped equivalent, thus negating any benefit from the approach. However, there is still a need to display images of better quality than those produced by graphic primitives.
To overcome this, the concept of Themes was incorporated into HGML. The principle here is that, in almost any web-site, it is possible to identify a core set of common images that reoccur on multiple pages throughout the site. Different sites will almost certainly represent such core images via a different set of graphics, but the core elements themselves are nevertheless relatively constant. Examples of such core images include page navigation buttons (e.g. previous, next, home, etc.), stylised bullet points and horizontal ruler / separator lines, etc.
At a high level, the image elements prescribed in HGML themes are split into three general categories :
Images of buttons for a range of relatively standard WWW pages functions. The structure of this category is strictly defined by HGML such that images are referenced by standard names and relate to the same type of image irrespective of the theme being used (i.e. HOME, BACK, NEXT, ARROW1, ARROW2, SEARCH, HELP, LINKS, FEEDBACK).
A range of standard page design constructs in terms of lines, bullets, separators etc. The structure of this category is strictly again defined and standard names are used irrespective of the current theme (i.e. LOGO, CORNER, LINE1 to LINE4, BULLET1 to BULLET4).
User-defined images of which the content is specific to the theme. HGML defines standard names (i.e. USER1 to USER10), but these do not provide any indication of the type of image being referenced.
HGML provides a default theme. Other themes (defined by individual site designers) will need to be downloaded the first time a service that uses them is accessed. This initial download would not be optimised, but would certainly be no slower than access the site via traditional HTML methods.
Whilst most sites will find a use for Navigation and Design related images, the other types of graphic that a site designer may wish to incorporate are far less predictable. As such, user-defined theme elements are provided to permit a degree of flexibility to developers, whilst still retaining optimisation advantages. This group allows local storage of other images, outside the standard categories prescribed. These may be used to reference any images that the site / theme designer wishes. It is generally anticipated that this will include images relating to corporate identity (i.e. logos etc.) to further standardise the look and feel of their pages. They could, however, also include additional line and bullet styles etc. that could not be encompassed under the standard headers provided.
It is left to the theme developer's discretion to ensure that the limited number of available "slots" for user-defined images are used wisely (i.e. careful selection based upon images that are likely to be required at several points within the site, rather than arbitrary inclusions that may not be reusable). It is suggested that the number of user-defined images be limited to ten in order to prevent the image repository from becoming undesirably large.
All images not included in the theme library will still need to be downloaded each time the site is accessed (unless they are still cached from a previous session). As such, it is sensible to utilise user-defined slots to hold the largest and most used images (thus helping to further optimise download times).
Given that the Navigation and Design categories have a prescribed content (i.e. the first element in the Design category is always a line, etc.), changing the theme associated with a page will mean that, whilst it looks different, the images displayed will still be meaningful and appropriate (e.g. a line will still appear where intended, albeit in a different style). By contrast, images in user-defined elements will be totally non-standard between different themes. As such, swapping the theme of a page will not be likely to yield meaningful alternatives for the user images (e.g. USER1 in Theme A may be a picture of computer, whilst in Theme B it represents a car).
The images would be retrieved from the theme library via tag sequences such as the following:
<CLIPART name=ARROW1, coords="10,10", width=20, height=50, href= "http://www.test.com/">
where
ARROW1 specifies the image to display
coords defines the position of the image
width and height specify optional dimensions
href specifies an optional hyperlink
Changing the theme (via a separate tag) would determine the exact appearance of the arrow that is displayed.
It should be noted that use of the theme library not only enables optimised page downloading, it also makes the creation of web sites easier, as it provides a ready-made stock of known images for a designer to utilise.
HGML is designed to meet the requirements of Internet appliances described above. It is designed based on the following principles.
An initial design decision for the new markup languages related to whether they should adhere to HTMLesque standards for command tags or whether a more minimalist approach should be taken. In usage terms, this meant a difference such as that shown below (based on the example of a LINE tag) :
HTML :
<LINE COORDS= "10, 10 , 20, 30", COLOR = RED, STYLE = "SOLID", PSIZE = "3">
Minimal :
LINE 10,10,20,30,3,1,3
Whilst both approaches would be equally functional, there was a natural leaning towards the HTML approach for the following reasons:
Whilst this results in a relatively verbose syntax,
further optimisation can be achieved prior to transmission by applying a compression
algorithm to the resulting text file.
HGML supports a total of 18 tags, which can be grouped into three functional categories, as shown below.
| Drawing Primitives | Image Theme | Image Manipulation |
| ARC ARROW ELLIPSE LINE LINETO LINEREL LINK ORIGIN POLYGON RECTANGLE SETSTYLE TEXT |
CLIPART THEME |
COPY FLIP PASTE ROTATE |
<!ENTITY % COORDS "CDATA" -- comma separated set of numbers
-->
<!ENTITY % STYLE "(solid | dotted)" -- option for line
style -->
<!ENTITY % PSIZE "(1 | 2 | 3 | 4 | 5)" -- point size
options for line thickness -->
<!ENTITY % COLOR "CDATA" -- a colour specification
#HHHHHH -->
<!ENTITY % URL "CDATA" -- attribute whose value is a
Uniform Resource Locator -->
<!ENTITY % AXIS "(horiz | vert)" -- indicates axis for
image manipulation -->
<!ENTITY % FONSTYLE "(plain | bold | italic)" --
indicates axis for image manipulation -->
<!ENTITY % FONT "(TimesRoman | Helvetica | Dialog)" --
indicates axis for image manipulation -->
The first group of tags provide HGML with basic drawing functionality, enabling the creation of a range of simple but effective composite images. Most commands include optional attributes for (out)line colour, style, thickness and, when appropriate, fill colour. If any of these that are not explicitly specified, the current default settings (as specified by the SETSTYLE tag) are used.
ARC
Draws an arc of a specified width, height and angle from absolute starting co-ordinates.
<!ELEMENT ARC - O EMPTY>
<!ATTLIST ARC
coords %COORDS #REQUIRED -- origin x,y co-ordinates of arc (absolute) followed by width, height, start angle and angle --
color %COLOR #IMPLIED -- line colour --
style %STYLE #IMPLIED -- line style --
psize %PSIZE #IMPLIED -- line thickness -- >
<arc coords="20,20,50,30,45,80", color=red>
ARROW
Draws a line from x1,y1 to x2,y2 using absolute screen (window) co-ordinates, with an arrowhead at the x2,y2 position.
<!ELEMENT ARROW - O EMPTY>
<!ATTLIST ARROW
coords %COORDS #REQUIRED -- start and end x,y co-ordinates (absolute) --
color %COLOR #IMPLIED -- line colour --
style %STYLE #IMPLIED -- line style --
psize %PSIZE #IMPLIED -- line thickness -- >
<arrow coords="10,10,100,100", color=black,
psize="2">
ELLIPSE
Draws an ellipse of a given width and height from the specified co-ordinates. This tag is also used to draw circles.
<!ELEMENT ELLIPSE - O EMPTY>
<!ATTLIST ELLIPSE
coords
%COORDS #REQUIRED
-- centre x,y co-ordinates (absolute) followed by width and
height --
color
%COLOR
#IMPLIED
-- outline colour --
fill
%COLOR
#IMPLIED
-- fill colour --
style
%STYLE
#IMPLIED
-- outline style --
psize
%PSIZE
#IMPLIED
-- outline thickness -- >
<ellipse coords="200,200,100,50", color=black,
fill=yellow>
LINE
Draws a line from x1,y1 to x2,y2 using absolute screen (window) co-ordinates.
<!ELEMENT LINE - O EMPTY>
<!ATTLIST LINE
coords
%COORDS #REQUIRED
-- start and end x,y co-ordinates (absolute) --
color
%COLOR
#IMPLIED
-- line colour --
style
%STYLE
#IMPLIED
-- line style --
psize
%PSIZE
#IMPLIED
-- line thickness -- >
<line coords="10,10,100,100", style="dotted",
psize="2">
LINETO
Draws a line from the current graphics cursor position to a new position (using absolute co-ordinates).
<!ELEMENT LINETO - O EMPTY>
<!ATTLIST LINETO
coords %COORDS #REQUIRED -- end of line x,y co-ordinates (absolute) --
color %COLOR #IMPLIED -- line colour --
style %STYLE #IMPLIED -- line style --
psize %PSIZE #IMPLIED -- line thickness -- >
<lineto coords= "200,150", color=green>
LINEREL
Draws a line relative to the current graphics cursor position using co-ordinate offsets.
<!ELEMENT LINEREL - O EMPTY>
<!ATTLIST LINEREL
coords %COORDS #REQUIRED -- end of line co-ordinates (relative) --
color %COLOR #IMPLIED -- line colour --
style %STYLE #IMPLIED -- line style --
psize %PSIZE #IMPLIED -- line thickness -- >
<linerel coords="15,-10", psize="4">
LINK
Allows a rectangular portion of the screen to be defined as an hyperlink.
<!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK
coords %COORDS #REQUIRED -- rectangular region, top left x,y co-ordinates (absolute) followed by width and height --
href %URL #REQUIRED -- this region will act as a hyperlink -->
<link coords="15,10,50,60",
href="http://www.demo.com/demo.hgm">
ORIGIN
Sets the position of the "graphics cursor". For use with LINETO and LINEREL tags.
<!ELEMENT ORIGIN - O EMPTY>
<!ATTLIST ORIGIN
coords %COORDS #REQUIRED -- new graphics cursor position x,y -->
<origin coords="100,130">
POLYGON
Draws a polygon using a list of absolute screen co-ordinates, starting with an origin. Co-ordinates are listed in the format "x1,y1,x2,y2,x3,y3...xn,yn". The line from the last specified co-ordinates back to the origin of the shape is drawn automatically to complete the polygon.
<!ELEMENT POLYGON - O EMPTY >
<!ATTLIST POLYGON
coords %COORDS #REQUIRED -- origin of shape, followed by n other points (all absolute co-ordinates) --
color %COLOR #IMPLIED -- outline colour --
fill %COLOR #IMPLIED -- fill colour --
style %STYLE #IMPLIED -- outline style --
psize %PSIZE #IMPLIED -- outline thickness -->
<-- six-sided shape -->
<polygon
coords="100,100,120,80,140,80,160,100,140,120,120,120", color=red, fill=red>
RECTANGLE
Draws a rectangle of a given width and height from the specified co-ordinates. This tag is also used to draw squares.
<!ELEMENT RECTANGLE - O EMPTY>
<!ATTLIST RECTANGLE
coords %COORDS #REQUIRED -- top left x,y co-ordinates (absolute) followed by width and height dimensions --
color %COLOR #IMPLIED -- outline colour --
fill %COLOR #IMPLIED -- fill colour --
style %STYLE #IMPLIED -- outline style --
psize %PSIZE #IMPLIED -- outline thickness -->
<rectangle coords="10,10,100,15",
style="dotted">
SETSTYLE
Enables default settings for outline colour, fill colour and outline style and thickness to be specified. These settings are then used unless explicitly overridden by the attributes in other HGML commands.
<!ELEMENT SETSTYLE - O EMPTY>
<!ATTLIST SETSTYLE
color %COLOR #IMPLIED -- outline colour --
style %STYLE #IMPLIED -- outline style --
psize %PSIZE #IMPLIED -- outline thickness -- >
<setstyle color=red, fill=green>
TEXT
Displays a text string, starting from the specified co-ordinates.
<!ELEMENT TEXT - O EMPTY>
<!ATTLIST TEXT
coords %COORDS #REQUIRED -- text position x,y co-ordinates (absolute) --
text CDATA #REQUIRED -- text string to display --
color %COLOR #IMPLIED -- text colour --
font %FONT #IMPLIED -- text font --
psize NUMBER #IMPLIED -- font size --
fstyle %FONSTYLE #IMPLIED -- font style -->
<text coords="10,50", text="This is an example of HGML
text">
HGML supports a standard range of pre-drawn images that may be used to provide further graphical content to a page, over and above that which may be easily achieved using the drawing primitives.
CLIPART
Enables an image to be retrieved from the local repository and displayed at the specified co-ordinates. The current theme will be used unless another one is explicitly specified. A scaling factor may be specified to dynamically resize the image and a hyperlink can be optionally provided.
<!ELEMENT CLIPART - O EMPTY>
<!ATTLIST CLIPART
name CDATA #REQUIRED -- image name --
theme CDATA #IMPLIED -- theme style --
coords %COORDS #REQUIRED -- top left co-ordinates of image --
width NUMBER #IMPLIED -- width of image (in pixels) --
height NUMBER #IMPLIED -- height of image (in pixels) --
href % URL #IMPLIED -- this image will act as a hyperlink -->
<clipart name=ARROW1, coords="50,50", width=150, height =
5, href= "http://www.demo.com/demo.hgm">
THEME
Enables a new default image theme to be selected.
<!ELEMENT THEME - O EMPTY>
<!ATTLIST THEME
name CDATA #IMPLIED -- name of image theme style -->
<theme name="DEFAULT">
HGML supports the manipulation of the onscreen bitmap image using COPY, PASTE, FLIP and ROTATE commands.
These are intended to further optimise the creation of certain types of image. For example, if a composite image created using several drawing primitives is also required at another onscreen location, then it may be copied and pasted rather than redrawn. The orientation of may then by changed using the FLIP and ROTATE operations.
The functions also help to optimise the storage of
theme images. For example, rather than store four Arrow symbols (pointing left, right, up
and down), a single image may be stored in the database and then ROTATEd and FLIPed as
desired.
COPY
Copies a specified rectangular screen segment to a memory buffer. The original image remains unchanged.
<!ELEMENT COPY - O EMPTY>
<!ATTLIST COPY
coords %COORDS #REQUIRED -- top left and bottom right co-ordinates of segment -- >
<copy coords="50,50,100,100">
FLIP
Performs a horizontal or vertical flip of a screen area defined by the specified co-ordinates.
<!ELEMENT FLIP - O EMPTY>
<!ATTLIST FLIP
coords %COORDS #REQUIRED -- top left and bottom right co-ordinates of segment --
axis %AXIS #REQUIRED -- horizontal or vertical flip -- >
<flip coords="50,50,100,100", axis="horiz">
PASTE
Copies the contents of a memory buffer to an appropriately sized rectangular screen segment, starting at the specified co-ordinates.
<!ELEMENT PASTE - O EMPTY>
<!ATTLIST PASTE
coords %COORDS #REQUIRED -- top left co-ordinates to paste segment -->
<paste coords="100,100">
ROTATE
Enables the rotation of an area of the screen window. The operation is restricted to performing 90-degree rotations of a square segment. The attribute "times" enables the number of rotations to be made (e.g. 3 = 270 degree rotation).
<!ELEMENT ROTATE - O EMPTY>
<!ATTLIST ROTATE
coords %COORDS #REQUIRED -- top left co-ordinates of area to be rotated and a single dimension to define a square segment --
times NUMBER #REQUIRED -- number of 90 degree rotations to perform -->
<rotate coords= "30,30,20", times=3>
In order to enable evaluation of the HGML concept in
practice, a prototype implementation has been developed. A trial was then conducted using
facilities provided by Orange Personal Communications Services Limited, a leading cellular
network operator and provider of mobile voice and data services in the UK.
As the aim of the prototype was that it could be "plugged in" to an existing browser, a number of options were available for implementation:
Due to external time constraints on the prototype implementation, it was decided to produce the prototype as a Java applet. While this would not provide the optimum in terms of execution speed, it provided a large amount of existing objects, for parsing, Internet communication and graphics, that could be exploited within the prototype. This meant that the prototype could be quickly developed and ready for trialing. The applet itself essentially comprised of two major areas of functionality: a HGML parser, which obtained and parsed the HGML script, and image construction, which would take the parsed HGML elements and construct the required image elements. The drawing code for each HGML element is encapsulated into its own object - as the HGML language definition was largely experimental this approach enabled the greatest flexibility in adding new elements to the prototype if necessary.
It should be noted that at the time of HGML prototype
development (May 1997), XML was only just starting to be introduced to the mainstream, and
the necessary software tools (e.g. an XML parser) were not available. However, it is
acknowledged that HGML could now be defined using XML (defined as an XML Document Type
Definition) and implemented using new XML software tools. If we review the prototype
implementation detailed in figure 3, then entire left hand side of the prototype can be
replaced with an XML parser. The remainder of the prototype could either be left as it is,
or also developed to exploit the newer developments in browser technology (e.g. DHTML,
more powerful scripting). It is conceivable that a full XML implementation of HGML could
be contained within the web page itself as script.
The direct comparison between HTML and HGML was facilitated through the design of a test page which was then implemented in both languages. The page was designed to incorporate a number of elements that might be found on a typical WWW page, as well as offering opportunities to utilise a number of the HGML features and optimisations (i.e. drawing primitives, clipart retrieval and image manipulation).
In the HTML implementation, this page was realised
using normal text and a series of inline images. In HGML, the page was constructed from a
combination of graphic primitive commands (creating aspects such as the text, the coloured
boxes and the three central illustrations) and theme image elements (for the navigation
buttons and bullet points). This led to a significant difference in terms of both the
overall size of the associated files and the time taken to download them over a wireless
link.
The following statistics present the contrast between traditional HTML/GIF images and HGML.
HTML |
HGML |
|
| File details | HTML file - 5KB GIF images - 83KB |
HTML file - 2KB HGML files - 13KB |
| Delivery time (via GSM)* | 1 minute 13 seconds | 18 seconds |
* includes time taken to
download and fully display / draw the page at 9600bps
The principal advantages of HGML when compared to traditional use of inline graphics in HTML are as follows :
In terms of limitations, it should be apparent that
the use of HGML is only applicable to certain types of image. For example, whilst basic
geometric shapes and vector images are straightforward enough to realise (and will yield
significant bandwidth saving over their GIF or JPEG counterpart), more complex images
(such as typical clipart and photographic images) would require many HGML instructions to
be sent over the link and would also more complex to draw on the client side (and hence
too time-consuming).
HGML is applicable to all types of Internet device, but is particularly suited to application in low bandwidth environments. This contributes to the general WWW community, especially for wireless remote and mobile devices.
The results of the trial implementation have
indicated that HGML offers significant promise as a means of improving web access in the
wireless domain.
Tim Berners-Lee and Dan Connolly, The HyperText Mark-up Language (HTML) Specification Version 2.0 (RFC 1866), Nov. 1995.
Dave Raggett, HTML 3.2 Reference Specification, W3C Recommendation. Jan. 1997.
Dave Raggett, Arnaud Le Hors, and Ian Jacobs, HTML 4.0 Reference Specification, W3C Recommendation, Dec. 1997.
Tim Hyland, Proposal for a Handheld Device Mark-up
Language (HDML), May. 1997.
The authors would like to thank the many Orange and PRP colleagues for their support and suggestions in the initial definition of HGML.
