Figure 1: A simple chart in an HTML page
Submission to the 6th WWW Conference
|
Fabio Vitali
Dept. of Computer Science
|
Chao-Min Chiu
Graduate School of Management
|
Michael Bieber
Institute for Integrated Systems Research
|
In this paper we introduce displets, a way to freely extend the HTML language on a per-document basis in a principled manner. Currently, the acceptable HTML elements are more or less those that have been approved by the official HTML review board. Non-standard extensions have appeared, and have relied on the commercial power of the proponents to be accepted.
There are two major forces driving the extension process of the HTML language: those who favour a better description of the elements of the documents, similarly to what happens with SGML, and those that would like better control on the final appearance of the documents, similarly to what happens with Postscript, and other display-oriented languages). Special notations (such as mathematics, music, etc.), are hardly -if at all - considered in the definition of this standard.
Displets are Java classes that are activated during the rendering of the HTML document. They provide graphical artists a better control on the final appearance of HTML documents, librarians and indexers a better description of their content, and those in need of new notations a way to describe and use graphical objects in a manner that is compatible with the graphical and structural habits of the HTML community.
The current debate on HTML sees two opposing positions as preeminent: on the one hand, some ask for a better control on the final appearance (the rendering) of the document; on the other hand, some advocate a better control on the description of the structure and role of the parts of these documents.
The first group, lead by graphic designers, would like the standardization efforts on HTML to stop and ad hoc extensions to the language be allowed plenty and numerous, covering all their different visualization needs. The second group, the SGML community, would prefer HTML to abstract from the description of the physical appearance of the documents, and would leave to style sheets the final mapping of structural elements to their visual representation.
Furthermore, commercial software developers often find it irresistible to improve and detour from the published standard, and seek a commercial advantage by extending the language with new, proprietary tags ([15], [16], [17]). Their hope, of course, is to have users switch to their browser in order to be able to read and fully appreciate Web pages using those new tags.
Yet, it is our impression that all these approaches miss a key need of authors of distributed documents, the support for special notations. Such notations include (and are not limited to) specialized graphical objects (e.g., object oriented graphics, graphs, charts, etc.), specialized notation for specific fields (e.g., chemistry, electrical and electronic engineering, music, mathematics, software engineering, chess, etc.), specialized alphabets (e.g., hieroglyphics, cuneiform, etc.),special symbols (philosophical, religious, astrological, alchemical signs, etc.).
There is currently one major way to include these types of notation in an HTML document: by providing an image of the graphical depiction of the object. For particularly complex or dynamic objects, it is now possible to write Java applets that display the object in the browser as their sole effect. Some applets may have the specification of the object inside their code, making it therefore completely hidden, some others may refer to their parameters for the specification of the object, using an arcane and opaque syntax.
In this paper we suggest a different approach to extensions to the HTML language: displets are small Java modules similar to applets that are called whenever a pre-declared HTML tag is encountered in the parsing of the document, and that take care of the display operation for that HTML object. By declaring at the beginning of the document both the extensions that will be used in the document and the displet class needed for the display, it is possible to allow for any kind of customized extension to the HTML language without loss of generality, and maintaining wide-spread support and stylistic elegance.
A proof of concept implementation of displets has been created by modifying the 1.0 alpha3 release of the HotJava browser. Several extensions have been designed and implemented on that architecture.
The paper is structured as follows: in section 2, the current state of the HTML language is summarized. In section 3, the need for new notations is discussed. In section 4 displets are introduced and described. In section 5 some implementation details are given. In section 6, some extensions to HTML that we have created using displets, and some others that we would like to create, are described. Section 7 contains a series of suggestions on how to implement displets within existing and future standards.
The HTML language was designed as part of the World Wide Web effort at CERN at the beginning of the nineties. Its goal [1] was to provide an easy page description language suitable for:
HTML was designed to be an application of the Standard Generalized Markup Language (SGML, [13]), that is, a class of documents conforming to an SGML Document Type Definition (DTD) defining "HTML documents". SGML is an international standard for describing marked-up text in an electronic format. Its wide acceptance and influence are owed to several characteristics, among which we would like to underline ([22], [9]):
HTML is a specific document type described using an SGML DTD. As such, it inherits some of the qualities of SGML: it shows embedded markup with meaningful names, some constraints in the nesting of elements, and some structuring support (the header tags). On the other hand, being a single DTD, HTML has the drawbacks of being a closed document type: only the existing elements can be used and no extension can be created unless approved by the appropriate committee.
This fact has caused several problems in the development of the language itself. Since HTML+ [19], through HTML 2.0 [2] to HTML 3.2 [20], every proposed enhancement to the language has had to deal with an approval process, with the attacks of competing proposals, and with the need to keep the additional features simple, usable, and orthogonal to each other. Several extensions were first implemented in commercial software and then proposed to the language committee with the force of an already wide-spread usage.
Some more needs could have been met with further language extensions (e.g. math markup [7]), but had little support from influential user bases or commercial software, were deemed too complex for fast implementation or no consensus was reached among the competing proposals. Therefore, these needs have to be met in the meantime with different, more complex and less elegant solutions: in-line images have for a long time been the standard way to include content elements whose graphical depiction was outside HTML, but they constitute rendering, and not content; server-side extensions (e.g., [11]) make it possible to specify new tags that are automatically substituted by an appropriate content before being delivered to the browser. They rely on the fact that even though a document needs to be shown on several types of browsers, it still resides on only one server, so that it is safe to include new tags which the server is aware of.
In the current discussion, graphic designers compete with SGML enthusiast to provide new extensions. Extremists appear on both sides: David Siegel [21] for instance proposes all standardization in the HTML language to be stopped at the current state, and suggests that the market decide on the successful extensions via natural selection of the fittest, while C. M. Sperberg-McQueen and R. F. Goldstein [23] suggests to use pure SGML documents and activate SGML viewers as plug-ins or external viewers.
Others have more moderate views: for instance, in the last W3C Workshop on High Quality Printing from the Web, April 1996, several proposals for consistent font rendering over the Web ([24], [26]), or new markup elements for the management of the display [6] were proposed, while at the First International Workshop on WWW Design Issues, November 1994, some discussed ways to include SGML features in the Web, by improving the structure control ([18], [25]), or by suggesting the development of several simplified SGML-like dialects to use instead of HTML ([10]).
An important class of proposals is the one that can show support from the W3C in one form or another. Stylesheets [4] are a way to attach rendering and formatting instructions to HTML tags. They allow the presentation to be specified in a precise way without cluttering the content of the documents. Style rules can be connected to HTML elements through implicit association, specification of linked stylesheet documents (with the LINK element), or the use of a new proposed header tag, called STYLE, where formatting instructions can be specified according to one of the possible stylesheet specification languages that exist ([12], [14]).
The Extensible Markup Language (XML, [5]) is an important proposal by the W3C Working Group on SGML. XML is a simplified SGML, so that XML documents are still valid SGML documents, in order to leverage on existing software, but the SGML syntax has been reduced of the more arcane features in order to produce a more usable and understandable language.
The previous discussion shows that whatever new extension is proposed, it is due to annoy or be ignored by a consistent authoring community: if the extension is related to rendering, it will cause critics by the SGML community; if it is related to content or structure, it will be ignored by graphic designers, that will go on doing HTML hacks or creating GIF images until some exact effect in their pages on some specific (and high-end) browsers will be obtained, with disregard for compatibility and content analysis. The need for an approval process by the HTML editorial review board and an implementation on commercial applications contributes to the shared discomfort.
Suppose we need to display in a Web browser the following chart:
Figure 1: A simple chart in an HTML page
Currently a few solutions are possible:
In the first case, the chart is static and fixed, and, when changing the data, we would have to redraw the picture using whatever application we used the first time. In the second case, we would have to mess with CGI scripting and with the dynamic generation of GIF files. In the third case, we would have to write our own Java applet or use an existing one and learn how to pass the parameters to it.
Obviously, the latter solution is probably the most elegant and common one given the current availability of tools. Unfortunately, this solution shares with the other ones a big drawback: the data that form the charts is not in an easily understandable or reusable format, as it is dictated by the syntax of the applet parameters. In short, the programmer of the applet decides how to specify the chart data, without any necessary similarity with the markup of the rest of the page, and with several restrictions on the available character set (we cannot, for instance, use angle brackets or double quotes in the text to be drawn).
Furthermore, the content of the applet is completely separated from the content of the page: it is not possible to make use of hypertextual features (such as links on the objects), to display HTML text in the labels, to deduce the relative numeric data, to let human readers understand the chart data by reading the HTML source code, or to have bots, indexers and research engines understand its content, unless the applet programmer has gone much out of his/her way to duplicate these characteristics from the browser in the code of the applet itself.
Therefore, while applets have the procedural power to support all needed notations, they don't mix at all with content markup, both in syntax and in structure, and are not an elegant choice for new data objects.
The ideal solution would be to specify the chart data as markup included in the HTML source code, instead of as parameters of the applet. Unfortunately this is currently not possible. Yet the whole point of structured markup à la SGML is to be able to name and describe in a significant manner all the parts of a document. The whole point of typographic languages à la Post Script is to be able to specify exactly how and where to display all the parts of a document. HTML forces instead all the parts of a document to fit in a limited set of available markup tags, and makes sure that the control on rendering is significantly removed from the authors.
Displets are our proposal for creating HTML extensions in a principled, general way that will satisfy both disputing communities and the generic HTML author:
Displets are Java modules that are automatically activated whenever some pre-declared tags are parsed by the HTML parser during the display of the HTML document. The author will be able to include any kind of tag provided some displet exists to handle the data thus specified.
Displets are specified within HTML documents as new markup tags. They are preceded by their declaration, and then used within the document as if they were legal HTML markup.
An example of an HTML document enhanced with displets may help in understanding their use:
<HTML><HEAD>
<TITLE>Test for chart</TITLE>
<TAG NAME="CHART" HasEndTag NonNesting SRC="http://hertz.njit.edu/chart/chart.class">
<ATTR NAME="type" VALUE="BAR, PIE, LINE" REQUIRED>
<ATTR NAME="width" VALUE=number>
<ATTR NAME="height" VALUE=number>
</TAG>
<TAG NAME="TABLE" HasEndTag IN="Chart"SRC="http://hertz.njit.edu/chart/table.class">
<ATTR NAME="HasLegend" VALUE=boolean>
</TAG>
<TAG NAME="TR" HasEndTag IN="Chart"SRC="http://hertz.njit.edu/chart/tr.class">
<ATTR NAME="Type" VALUE="LABEL, DATA" REQUIRED>
<ATTR NAME="Color" VALUE=RGB>
</TAG>
<TAG NAME="TH" IN="Chart"SRC="http://hertz.njit.edu/chart/th.class"></TAG>
<TAG NAME="TD" IN="Chart"SRC="http://hertz.njit.edu/chart/td.class"></TAG>
</HEAD><BODY>
<P>Some normal HTML text followed by the chart:</P>
<CHART TYPE=BAR> <TABLE HasLegend>
<TR TYPE=LABEL>
<TH> <TH><EM>Jan/Mar</EM> <TH>Apr/Jun <TH>Jul/Sep <TH>Oct/Dec
</TR>
<TR TYPE=DATA COLOR=RED>
<TH>Smith <TD>125 <TD>257 <TD>327 <TD>250
</TR>
<TR TYPE=DATA COLOR=GREEN>
<TH>Green <TD>137 <TD>140 <TD>110 <TD>160
</TR>
<TR TYPE=DATA COLOR=BLUE>
<TH>Brown <TD>421 <TD>380 <TD>250 <TD>150
</TR>
</TABLE> </CHART>
</BODY></HTML> |
A displet-enhanced HTML document has two new characteristics: at the beginning of the document, the new tags are introduced with a simple syntax. Then, in the body, the newly defined tags are liberally used and mixed with standard HTML ones to create the needed document.
According to this syntax (others can be defined; a discussion on some likely ones can be found in section 7), for each tag the main characteristics are described in a simplified syntax that closely resembles SGML DTDs: the name of the tag, the syntax constraints, and the available attributes. There are two major difference from DTDs:
As the example shows, some tags have not been defined from scratch, but are a customization of existing ones. This allows non-compliant browsers to still make use of the content of the document and display it as best as it can.
For instance, leveraging the fact that unknown tags and attributes are usually ignored by browsers, we are re-using TABLE, TR, TH and TD tags for specifying the charting data. Therefore an unaware browser would display the previous document as containing an appropriately formatted table:
By specifying the IN="Chart" attribute within the table-related tags, we signal that the code of the displets should be called only when these tags are found within a CHART tag, so that tables described outside of charts are still handled normally.
This solution should appeal to SGML enthusiasts because the HTML language can be extended with new tags, so that structuring the documents is more flexible and complete, the new tags are explicitly defined, and some syntactical description (albeit simpler than in SGML) is described.
It also should appeal to graphical designers, because page designers are not constrained to forcing their graphical ideas into existing tags, and final rendering of the elements can be finely controlled by the displet code.
Furthermore, it should appeal to those with special notation needs, because whole new notations can be defined (mathematics, music, etc.), as well as simple elements (special characters, dingbats, etc.), or complex structured data formats (object-oriented graphics, charts, etc.), and these can be easily included in HTML documents sharing the same ease of use and comprehension as the other HTML tags.
Finally, it may appeal to HTML rulers, because it is the only method so far to extend HTML without recurring to the endless discussions of committees, to the market force of commercial software, or to the complex specification mechanisms of SGML and XML.
4.2 Displets as Java modules
A displet is a Java class whose methods are called during the parse of an HTML document. Displets have control over the display of themselves and their immediate surroundings, such as the HTML code contained between their start and end tag, or immediately following the end tag. They are not usually called while the document is on screen, unless the displet explicitly requests this service.
The Java code for a very simple displet looks like this:
import awt.Graphics;
class HelloWorldDisplet extends browser.Displet {
public void startElement() {
graphic.drawString("Hello world!", 10, 25);
}
} |
In order to work, displets require a modified HTML parser that allows external classes to be declared and invoked and that allows external classes to modify the rendering parameters (such as text font, size or style, margins, etc.).
The modified HTML parser must accept the definition of the new tags upon encountering the TAG element, and invoke the appropriate methods when encountering the start and end tag of the newly defined element.
Whenever encountering an unknown tag, the HTML parser should verify if a TAG tag with that name has been defined and that can happen in the current context (for instance, if it follows the specifications of the IN and NonNested attributes). If so, it will create a new instance of the displet providing also an array of the valid attributes (as specified by the ATTR elements contained in the TAG element). Similarly will happen if and when the end tag of the newly defined tag is encountered.
Upon displaying the page, the startElement() method of the displet should be called correspondingly to the start tag. Within this method it is possible to create graphical objects and to change the settings of the current rendering (font, margins, etc.).The endElement() method is called in correspondence with the end tag of the new element. This method should usually be used to restore the original settings that were modified in the startElement() method.
Furthermore, the browser should be capable of calling the appropriate methods whenever a user event happens within the boundaries of the displayed object. This need is clearly shown for the A tags, where it is necessary for the browser to react when the user clicks or moves the mouse over the displayed object.
We have created a proof-of-concept implementation of displets, using Java 1.0 alpha3 and the 1.0 alpha3 release of the HotJava browser. Although this forced us to use a non-standard and outdated version of the language, and a limited set of HTML options to start off with, it allowed us to use the source code of an existing HTML parser and browser that we could modify and extend.
HotJava 1.0 alpha3 parses and displays HTML documents by the interaction of the appropriate subclasses of three different classes: Tag, TagRef and DisplayItem. Tag instances (one for each tag type) are passive objects that simply notify the HTML parser of their existence. TagRef instances are created by the HTML parser every time it encounters the proper tag, and are used as an internal representation of the HTML document. When displaying the document, each TagRef is associated to a relevant DisplayItem, which decides how to display itself.
The current implementation therefore defines two new tags: TAG and ATTR:
<!ELEMENT tag - o attr*>
<!ATTLIST tag
name CDATA #REQUIRED
hasEndTag (hasEndTag | NoEndTag) "NoEndTag"
nesting (Nesting | nonNesting) "Nesting"
interactive (Interactive | nonInteractive) "nonInteractive"
in CDATA #IMPLIED
src CDATA #REQUIRED>
<!ELEMENT attr - o (#PCDATA)?>
<!ATTLIST attr
name CDATA #REQUIRED
value CDATA #REQUIRED
required (required | nonRequired) "nonRequired">
|
Three classes are defined, namely the DispletTagRef, DispletDisplayItem and Displet. A DispletTagRef is created whenever a declared new tag is encountered during the parse of the document. The DispletDisplayItem is then activated by the browser during the layout of the document page. This class creates an instance of the appropriate Displet class (the only class supplied by the user), which can create a graphic object or modify the layout settings as needed.
If the INTERACTIVE attribute is specified, the displet class will also receive all the users' events in the area, as the appropriate methods (mouseDown(), mouseUp(), etc.) will be called. An interactive displet can do exactly the same things as an applet, although the calling method is different (displets should prepare and paint themselves in the startElement() method).
This structure is parallel and similar to the one used for managing applets:
Figure 2: The analogy between applets and displets
The user implementing a new displet should therefore simply subclass Displet. Displets are built around two basic methods: startElement() and endElement(). In the first one, a displet should prepare and draw its graphical representation and/or modify the current setting for the next elements. In the second one, a displet should restore the original settings. Two objects are available to all methods in a displet class: the graphic object, providing the context for the drawing routines, and the document object, providing the current values for variables such as the current margins, the current font, etc.
In our proof-of-concept implementation, we have created a small set of working extensions to HTML. A few more are in the works, and should be ready at about the conference time.
A chart is a graphical depiction of a table of numerical values. In accordance to this definition, and trying to preserve compatibility with other browsers, charts use table tags to define the data they need to show. A complete example of the grammar and use of charts is given in sections 3 and 4.
A graph is a set of circular and rectangular shapes called nodes connected by arrowed lines called arcs. The following is the declaration of such a displet in the HTML document:
<HTML><HEAD>
<tag name="GRAPH" hasEndTag nonNesting src="http://hertz.njit.edu/displets/graph/GRAPH.class">
<attr name="width" value=number>
<attr name="height" value=number>
</tag>
<tag name="NODE" hasEndTag nonNesting in="GRAPH"
src="http://hertz.njit.edu/displets/graph/node.class">
<attr name="name" value=string required>
<attr name="pos" value=integerPair>
<attr name="size" value=integer>
<attr name="shape" value="rect , circle">rect</attr>
</tag>
<tag name="ARC" hasEndTag nonNesting in="GRAPH"
src="http://hertz.njit.edu/displets/graph/arc.class">
<attr name="name" value=string>
<attr name="from" value=string required>
<attr name="to" value=string required>
<attr name="arrow" value="to, from">
<attr name="thickness" value=integer>
</tag>
</HEAD><BODY>
<graph width=400 height=300>
<node name="first" pos=290,120 size=160,40 shape=rect>
<A HREF="http://hertz.njit.edu/first.html">This is the first label</A>
</node>
<node name="second" pos=100,20 size=160,40 shape=rect>
<B>This is the second label</B>
</node>
<node name="third" pos=100,120 size=120,50 shape=rect>
<arc from="first" to="second" arrow=from>This has a label, too</arc>
<arc from="first" to="third" arrow=from>
</graph>
</BODY></HTML>
|
This is how the graph looks on the screen:
Figure 3: A graph element in an HTML page
Anchor groups are a way to implement multi-endpoint links [3]. the user finds a clickable area that, instead of leading to a single destination, pops up a list of choices each leading to a different destination. As a displet, this corresponds as an anchorGroup tag surrounding a set of plain HTML A anchors.
The following is a declaration for AnchorGroup:
<HTML><HEAD>
<tag name="agroup" hasEndTag interactive src="http://hertz.njit.edu/displets/agroup/agroup.class">
<attr name="name" value=string>
<attr name="align" value="top, middle, bottom">
</tag>
<tag name="a" hasEndTag src="http://hertz.njit.edu/displets/agroup/a.class">
<attr name="HREF" value=URL required>
<attr name="ALT" value=string>
<attr name="selected" value=boolean>
</tag>
</HEAD><BODY>
<agroup name="agroup1" align="top">
This is an example of multi-endpoint link:
<a href="http://www.njit.edu" selected>Go to NJIT</a>,
<a href="http://info.rutgers.edu">Go to Rutgers</a>
</agroup>
</BODY></HTML>
|
By defining anchor groups as collections of anchors, we can guarantee some compatibility with existing browsers, since the links, rather than being grouped in a single pop-up menu, will be displayed side by side without problems.
Figure 4: An anchor group in an HTML document
Anchor labels are small pop-up windows that appear near an anchor when the user moves the mouse near it. It may contain a small sentence explaining the purpose and the destination of the link. Anchor labels are implemented by extending the definition of anchors, i.e. by adding a new attribute to the A tag.
<HTML><HEAD>
<tag name="a" hasEndTag nonNesting interactive src="http://hertz.njit.edu/displets/label/a.class">
<attr name="HREF" value=URL required>
<attr name="ALT" value=string>
<attr name="LABEL" value=string>
</tag>
</HEAD><BODY>
<P>Please check <a href="http://www.njit.edu" label="This
link will lead to the NJIT website">here</a> for a description
of NJIT.</P>
</BODY></HTML>
|
Figure 5: An anchor label in an HTML document
It is important to distinguish the idea of displets from the details of the architecture that we have implemented. Some of our design decisions were driven by the need to use a specific platform choice, and need to be modified in new implementations using current software. Some others were choices among equivalent candidates, and can be rediscussed in other implementations.
For instance, the creation of the Displet, DispletTagRef and DispletDisplayItem classes are due to the use of the HotJava alpha browser, which uses similar classes for its functions. A different implementation using more recent software will require rethinking the set of classes to be used. On the contrary, the choice of creating Java modules, rather than, for instance, ActiveX objects or Python scripts, is probably still sound, but open to be rediscussed in different implementations.
On the other hand, our real contribution is the idea of displets, of which we will summarize the core aspects:
One choice is particularly open to debate: how should new elements be specified? Our choice has been to create two new tags, TAG and ATTR, to be used in the HEAD part of an HTML document, where the new elements can be defined and the rendering code, the displet, is specified. Another choice would be to extend stylesheet standards so as to allow the specification of the URL of the displet as a style parameter. For instance:
<TAG NAME="MYTAG">
<ATTR NAME="first" VALUE=string>
</TAG>
<STYLE TYPE="text/css">
H1 { color: red }
MYTAG { src: "http://hertz.njit.edu/displets/label/a.class" }
</STYLE>
|
We believe that our choice is the easiest to implement and to understand, but it has two drawbacks:
We should note that any extension syntax defined on a per-document basis will face the same problems. Solutions include using a specific DTD for the new elements and relying on the proposal for specifying HTML Dialects [8], or performing major reworking of the current HTML DTD, so as to allow the specifications of new elements, and the substitution of the standard DTD invocation:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> |
with a new syntax that allow the DTD to be extended on the fly. A possible syntax would be:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN" [ <!element mytag - - (#PCDATA)> ... etc ... ]> |
It is our opinion, though, that this kind of syntax would be much more obscure to the casual author, and that it would be better to obtain SGML compliance only when needed by applying a simple pre-parser to the extended documents. Similar considerations can be done for XML compliance.
Given the current success of the Web, more and more people will need to make non-textual content available to a large number of users. HTML is a compromise between the need to render the content in an interesting way and to maintain easy analysis and computability over the content itself.
Unfortunately, being a closed language, HTML has allowed tricks and hacks to become commonplace whenever a graphical effect or some structuring are needed that go beyond the expressive power of the language itself.
Displets are a proposal to allow arbitrary extensions to be defined within HTML documents without reverting to the complexity of SGML or XML, and without losing the control on structure that page-description languages may impose.
The current implementation is just a proof-of-concept, admittedly, but it shows the strong potential of allowing the definition of new elements as well as the specification of the code for their correct rendering.
Displets, without giving up to the evident simplicity in design and use of HTML, allow sophsticated graphical effects, as well as better definition of structural elements, as well as the specification of new, arbitrarily complex notations that are not currently supported by any browser except through inline images. We believe that the ideas proposed here should be implemented on a large scale.
| [1] | T. Berners-Lee, D. Connolly, Hypertext Markup Language 1.0, http://ecco.bsee.swin.edu.au/text/html-spec/HTML.html |
|---|---|
| [2] | T. Berners-Lee, D. Connolly, Hypertext Markup Language - 2.0, http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_toc.html |
| [3] | M. Bieber, F. Vitali, H. Ashman, V. Balasubramanian, H. Oinas-Kukkonen, "Fourth Generation Hypermedia: Some Missing Links for the World Wide Web", forthcoming in International Journal on Human-Computer Systems. |
| [4] | B. Bos, D. Raggett, H. Lie, "HTML3 and Style Sheets", W3C Working Draft, http://www.w3.org/pub/WWW/TR/WD-style |
| [5] | T. Bray, C. M. Sperberg-McQueen (eds.), "Extensible Markup Language (XML)", W3C Working Draft, http://www.textuality.com/sgml-erb/WD-xml.html |
| [6] | S. Butler, R. MacMillan, S. Waters, "HTML Extensions To Improve Layout Control for Viewing and Printing Documents", W3C Workshop on High Quality Printing from the Web, http://www.w3.org/pub/WWW/Printing/fmtext.html |
| [7] | D. W. Connolly, Math Markup, W3C page, http://www.w3.org/pub/WWW/MarkUp/Math/ |
| [8] | D. W. Connolly, "HTML Dialects: Internet Media and SGML Document Types", W3C Working Draft, http://www.w3.org/pub/WWW/TR/WD-doctypes |
| [9] | Steve De Rose, David Durand, "HyTime", Kluwer, 1994. |
| [10] | P. Duval, "SGML-based dialects for WEB applications based upon content-understanding", International Workshop on WWW Design Issues '94, http://www.cwi.nl/ERCIM/W4G/WS94/papers/Patrick.html |
| [11] | HTMLscript, HTMLscript |
| [12] | ISO-IEC, "Information technology --- Processing languages --- Document Style Semantics and Specification Language (DSSSL)", http://occam.sjf.novell.com:8080/dsssl/dsssl96 |
| [13] | INTERNATIONAL STANDARDS ORGANISATION, ISO 8879, Information Processing - Text and Office Systems - Standard Generalized Markup Language (SGML). |
| [14] | H. Lie, B. Bos, "Cascading Style Sheets, level 1", W3C Proposed Recommendation, http://www.w3.org/pub/WWW/TR/PR-CSS1 |
| [15] | Microsoft, HTML Authoring Features for Internet Explorer 3.0, http://www.microsoft.com/workshop/author/newfeat/ie30html-f.htm |
| [16] | Netscape, "EXTENSIONS TO HTML 2.0", http://home.netscape.com/assist/net_sites/html_extensions.html |
| [17] | Netscape, "EXTENSIONS TO HTML 3.0", http://home.netscape.com/assist/net_sites/html_extensions_3.html |
| [18] | V. Quint, "Should WWW documents be structured?", International Workshop on WWW Design Issues '94, http://www.cwi.nl/ERCIM/W4G/WS94/papers/Quint.html |
| [19] | D. Raggett, "A Review of the HTML+ Document Format", Proceedings of the First WWW Conference, Geneva (CH) 1994, http://www1.cern.ch/PapersWWW94/dsr.ps |
| [20] | D. Raggett, HTML 3.2 Reference Specification, http://www.w3.org/pub/WWW/TR/PR-html32-961105 |
| [21] | D. Siegel, The balkanization of the Web, http://www.dsiegel.com/balkanization/ |
| [22] | C.M. Sperberg-McQueen and Lou Burnard (eds.), Guidelines for Electronic Text Encoding and Interchange, chapter 2, "A Gentle Introduction to SGML", ftp://www.ucc.ie/pub/sgml/p2sg.ps |
| [23] | C. M. Sperberg-McQueen and R. F. Goldstein, "HTML to the Max: A Manifesto for Adding SGML Intelligence to the World-Wide Web", Electronic Proceedings of the Second World Wide Web Conference '94: Mosaic and the Web, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Autools/sperberg-mcqueen/sperberg.html |
| [24] | R. Stevahn, "PANOSE: An Ideal Typeface Matching System for the Web", W3C Workshop on High Quality Printing from the Web, http://www.w3.org/pub/WWW/Printing/stevahn.html |
| [25] | A-M Vercoustre, "Adding SGML to WWW", International Workshop on WWW Design Issues '94, http://pauillac.inria.fr/~vercous/WWW.html |
| [26] | S. Zilles, "Quality Printing on the Web", W3C Workshop on High Quality Printing from the Web, http://www.w3.org/pub/WWW/Printing/zilles.html |