Standards to Support National Cooperation in Applying Technology to VET
Whether at home, work or at the training institute, there are three global networks which enable the two-way communication which is vital for flexible delivery: the telephone network, the postal system and the Internet. The Internet is faster than the post and more cost-effective in many situations than the post or telephone. It is a relatively simple, flexible network which supports sophisticated and easy-to-use applications because it connects directly to the user's computer, which can run a wide variety of software which can communicate instantly with any other Internet-connected computer.
A dial-up Internet connection suffers from low and uncertain transmission speed - which precludes the use of demanding applications such as videoconferencing - but within these limits, it is a superb communication system for flexible delivery.
For most users, email will be a very important aspect of Internet communications. Email is discussed in an earlier section. This attachment is concerned with a wide variety of other protocols - most particularly those associated with what is loosely called the "World Wide Web".
The focus here is on choosing technologies and the means of using them to best facilitate flexible delivery. The choice of technologies in this field typically has no direct cost implications, since most of it is implemented in freely available software. However, in order to achieve clear communication, in a sophisticated and approachable way, complex technologies must be used wisely. This can only be achieved when teachers are supported with proper in-service training, support staff, and appropriate hardware, software, Internet access and other forms of support - such as email discussion lists and web-forums for teachers with a common field of interest.
The official Internet standard protocols are intended to maximise interoperability - in contrast to some proprietary protocols which are also used widely. In many aspects of Internet communication, there is only one applicable standard, or a standard such as HTTP 1.0 which is superseded by the compatible HTTP 1.1 - so there is little or nothing to choose between or standardise for VET purposes. Conversely, since Internet communications is evolving rapidly there are quite a number of fields in which standards and deployed technologies are conflicting, incomplete or partially adopted - leading to interoperability and performance difficulties for the VET sector's use of the Internet for flexible delivery.
One major constraint on interoperability is the
technical capabilities of the computers of those who need to
interact with the VET institute via the Internet. These may be
learners involved in distance education, or potential learners
and their employers. This is particularly so of Web based
communications, because of bandwidth and browser software
limitations. For instance if every learner had an up-to-date PC
and an uncongested multi-Mb/s link through the Internet to the
institute, then flexible delivery could use such highly
communicative, but bandwidth-intensive, approaches such as
video-conferencing.
Interoperability for Internet communications can best be assured
by finding approaches which work reliably with restricted
bandwidth, without assuming too much about the user's PC or
web-browser and which provide a rich communicative environment in
a form which technically inexperienced users will be happy to
use.
This attachment focuses on these Web access questions, particularly regarding HTML standards, Java, Active-X and portable document formats.
While multicasting is technically possible, it is insufficiently practical at present to be discussed here.
Any institute which uses the Internet - and particularly those flexible delivery providers who service many learners via the Internet - faces some challenging problems with the security of their network and protection against malicious use of its services. Computer security is a vital and rapidly involving field. There may be arguments for setting standards for the level of security and privacy must be achieved by VET providers - or for standardising the means of achieving this to enhance interoperability nationally - but this is too demanding a field to be covered here.
One area of difficulty for flexible delivery is the tension between three priorities:
The desire to maximise Internet connectivity and computing resources for users inside and outside the VET institute when accessing resources within the institute and, similarly, the desire to maximise connectivity of local users to the Internet outside the institute.
The desire to minimise bandwidth, network management costs and computer support costs.
The desire to maximise security, most typically by restricting the communication and computing activities of users, in terms of bandwidth and/or by allowing only a small set of protocols.
Flexible delivery can best be achieved when there are minimal barriers to communication, when the network and link to the Internet support all protocols - including novel protocols for innovative software - and where the network and its computers are nonetheless secure against misuse and attack.
The solution lies in adequate resources for computers, routers etc. and for suitably high capacity links to the Internet - and in well-resourced staff who can manage the network and provide support for teachers and learners.
3. Current Approaches in the VET Sector
The current status of Internet technology in the VET sector is shown in the following diagram
| . | Application Objectives |
No. of students |
No. sites |
Metro/ Regional |
Existing Technology/ Standards |
| NSW TAFE | Educational delivery | Approx 27,000 full time 270,000 part time |
2300 schools, 12 institutes/250 colleges | Metro & Regional | No streaming allowed across WAN links, JAVA allowed, SMTP, POP3, NTP, HTTP, FTP, IRC CHAT can be used internally (more protocols will be allowed with the new firewall) |
| SA DETAFE | Multiple including online
delivery, information services and corporate Intranet
Standards based Development Tool |
2000 - 3000 | 60+ Internet | 50/50 | SMTP/MIME POP3 NTP Webforum IRC Majordomo Some Java CGI predominantly Perl Ph: DNS Active Server Pages |
| ACT CIT | Education Delivery
Information Services Corporate Internet |
||||
| VIC | State WAN | VicOne with VETNET subnetwork | |||
| NT | 286, some secondary schools | WAN intranet | |||
| TAS | Education and student accounts via POP server | Groupwise | |||
| WA | Administrative and academic | 72 nodes | restrictive with case by case review | ||
| QLD | Email, limited HTTP | All TAFE colleges and regional offices on WAN | HTTP, SMTP |
The basic transport standard of the Web, HTTP 1.0, is about to be replaced by a higher performance and backward-compatible version 1.1. This will improve the speed and functionality of the Web. Currently, each file in a web page - the HTML page itself and every graphic file it contains - must be retrieved with a separate, independent HTTP session, each of which is based on its own TCP session. This involves significant handshaking and communications overhead for each file. HTTP 1.1 enables multiple files from the same server to be retrieved in a single HTTP session.
Servers and browsers are expected to adopt HTTP 1.1 rapidly, but older software will continue to interoperate normally. Therefore HTTP 1.1 does not raise interoperability questions for VET organisations. VET will naturally adopt HTTP 1.1 as browser and server software is updated.
There are four areas of Web-based communications where protocols, file formats and usage are unstable in ways which are likely to detract from VET's goals of interoperability with a wide range of remote users. These areas are:
1 HTML text, graphics, video and sound - and web page and site
design.
2 Web programming and application interfacing: Java vs. Active-X
3 File formats - especially 'portable document' formats, but also
word processing, graphics and spreadsheet formats.
4 Metadata - hidden information in web pages to aid indexing.
The first three areas are characterised by rapid technical
evolution, rapid growth of the user base, increasingly complex
and diverse requirements of users and the resultant tensions
which arise between software companies and standards
organisations. There is a further tension between the desire of
some organisations to create an impression of sophistication and
impressive technical and financial resources and the desire of
most users for clear, easily navigable, quickly accessible
information.
Some of the current problems will be solved within a year or so
as the HTTP 1.1 protocol and HTML 4.0 specification become
adopted. HTML 4.0 in particular will enable much more
sophisticated control of screen and printed presentation of text
and graphics.
The Internet Engineering Task Force (IETF) is responsible for all the lower level standards of Internet communication, such as TCP/IP, routing and the Domain Name System. Similarly the IETF is responsible for basic 'application' protocols, such as Telnet, FTP, SMTP, HTTP and many others. See:
http://www.ietf.org
and:
http://rs.internic.net/
Many other protocols and file formats which are important in Internet communications, for instance voice communication protocols, HTML and Adobe Inc's Portable Document Format, come from companies and other organisations such as the World Wide Web Consortium (W3C).
Many of these Internet standards do not arise from the mainstream formal standards organisations, but the processes of the IETF and the W3C are generally as open, public and well-respected as those of the more established standards bodies.
This discussion concentrates on the protocols and file formats of the World Wide Web - and on guidelines for using these in ways which best support flexible delivery. The primary organisation which is responsible for these standards is the World Wide Web Consortium (W3C) (http://www.w3c.org/), which works with the IETF, although many companies are also active in creating and attempting to standardise their proprietary approaches. The W3C site is the authoritative source of information on many technical and social aspects of Web communications.
Technical standards for HTML concern which kinds of tags should be used in Web documents, and which browsers should be used to ensure acceptable or identical interpretation of the one document. This is a rapidly evolving field, with a base set of HTML standards - the W3C's HTML 4.0 replacing version 3.2 and the proprietary extensions by both Netscape and Microsoft which are implemented in their competing browsers.
Within Web documents there is a need for still graphic images, and .GIF and .JPG formats are generally sufficient for this at present. There is little need for VET standardisation here, because prevailing Web practice is simply to use one of these formats and there are no interoperability problems. However a new format - .PNG (Portable Network Graphic) - will be used in the future as well.
Animated graphics can be achieved with the widely supported .GIF format, or by a variety of proprietary standards such as MacroMedia's 'Shockwave', which also provides sound.
There are a number of competing open and proprietary standards for delivering sound. Open standards include MPEG Audio layer 2 and the higher performance layer 3 (MP3). The widely accepted standards '.WAV' and '.AU' can usually be played by multimedia PCs, but they do not offer the compactness of the MPEG formats, and so lead to much longer download times. Freeware players are widely available for MP3: http://www.mp3.com
Since the specification and decoder source code is freely available, this functionality can be built into other programs, although it is a highly CPU-intensive process. It is generally not possible to achieve better than speech quality audio in real-time through a dial-up Internet connection: any file containing quality reproduction of non-voice signals must be downloaded to hard-disk before it is played. However more efficient compression algorithms and 56 Kb/s modems are making real-time playing of music and other non-voice sounds more viable.
Proprietary standards include Real Audio, Liquid Audio and Netscape Streaming Audio. Support for these formats in the major browsers is improving rapidly.
Video formats include MPEG-1, Apple Quicktime and Windows AVI.
There are a number of competing standards for embodying complex computer programs in Web documents. These programs are run within the Web browser and may work with files and programs on the same computer, or on remote computers connected to the network, including the Internet. Sun's Java is the most prominent standard, but Microsoft's Active-X and VBScript are also contenders in this hotly contested field.
File formats for text and graphic documents, which aim to achieve portability between operating systems, include HTML, Adobe's Postscript and Acrobat .PDF formats and the various Microsoft Word file formats.
The following discussion reflects the workshop paper and discussions during the workshop regarding a variety of technical standards, functional requirements and operational guidelines, which if standardised, would facilitate VET flexible delivery. In some cases the rationale for the recommendations is obvious, so these are not listed here.
Some of the problems discussed below relate to technological problems with bandwidth and the evolving nature of web-browser and sound and video software. Others arise from poorly considered use of existing web functionality.
In the timeframe of standards emerging from this workshop, it seems reasonable to assume that VET web sites will be accessed by browsers which are compatible with HTML 3.2 and later 4.0.
Goals for VET HTML usage and web design may include:
1 - Ensuring compatibility with HTML 3.2.
2 - For the front, navigational and informational pages of VET web sites - if not the instructional pages - maximising accessibility to users who are using a text-mode browser, such as Lynx, or who are using Lynx or a graphic browser with a speech synthesiser. Therefore the material should be navigable in the absence of any graphic images - precluding the use of image-maps and any unlabelled images which form the sole means of linking to other pages.
3 - Avoiding the use of Java and Javascript unless they are the only way of achieving a genuinely communicative or instructive purpose.
4 - Minimising bandwidth and download time - by eliminating graphics and especially animated graphics except where they are the most communicative approach. Where graphics are used, it is best to specify their dimensions in the HTML. This enables the browser to lay the page out quickly and to fill in the graphics as they arrive. Without this, Netscape Navigator will not display much of the page until it has started retrieving all its graphics, and Internet Explorer continually reformats the page layout as it starts retrieving those files - leading to a highly distracting movement of some or all of the page's elements. Two common practices which cause one or both browsers to halt the display until all or most of the material has been received are: firstly not including image dimensions in the HTML, and secondly placing all or most of the text and other material inside a table.
5 - Simplifying the navigation. This involves measures such as avoiding the following:
- The use of frames unless there is no better way to present and organise the information. Frames make navigation and printing of pages more difficult, and typically do not allow the display of the URL of the currently visible page - making it more difficult to bookmark or refer others to particular pages.
- Overly long URLs.
- URLs which change dynamically.
- Overly complex site organisation.
- Large numbers of small pages where one longer page would suffice.
- Java-script ticker tape messages which are distracting and obscure the display of the URL when the cursor is placed over a hyperlink.
Image maps should be an optional method of navigation. Frequently used links should be placed near the top of pages, with clearly descriptive text descriptions, rather than at the bottom, where they may only become visible after graphics have loaded or the user has scrolled down hoping to find them.
Frames can play havoc with browser navigational tools such as Netscape's "Go" history list or the "Back" button. Few users know how to open a frame's contents in a separate window: it is a right-click in the frame with Netscape, and may not be possible with Internet Explorer.
6 - The avoidance of overly complex URLs or URLs which are likely to change from time-to-time - except where absolutely necessary as part of material which must be retrieved from a database. Such URLs may be so long as to be unintelligible to humans, too long to fit in the header of a hard-copy print-out and too long to be reliably cut and pasted into an email.
7 - Avoiding the use of material which can only be viewed with browser plugins - such as Shockwave - unless there is no better way of achieving a particular communicative purpose.
8 - Avoiding the user having to choose between "Frames" and "No-frames" versions of the site, and the error-prone practice of the web-server determining the browser capabilities in order to send it differing material.
9 - Avoiding the use of auto-load pages which quickly change the browser to another URL. This confuses the user and makes it more difficult for them to refer other people to the URL. This should only be used when a page has moved, and then the user should see a clear statement that this has occurred, for five or ten seconds, before the new URL is loaded.
10 - Unless there are compelling reasons, all Web sites should be designed for rapid viewing via an Internet connection which works at around 28.8 Kb/s on a 256 colour screen with resolution of 800x600 without the need for horizontal scrolling. Navigation and as much of the content as possible should be available to people using only a text-based browser, and the most important navigational links should appear near the top of the page within a few seconds.
11 - Avoiding the use of spaces within file names. Not all operating systems support such file names, and they make it harder for users to recognise it as a single file name rather than multiple names or words.
12 - Unless there are compelling reasons, avoiding using upper case characters for file and directory names. Lower case is often easier to read, and since most URLs are lower case, occasional upper case characters are distracting and may not be remembered if the URL is entered manually.
13 - Avoiding the use of special characters in file and directory names. These characters include slashes (forwards and backwards), "?", "*" and others which may not be compatible with all operating systems.
14 - When linking to an external site, make it clear to the user that this link leads to a separate site and the user needs to press the back button to return. This is particularly important in instructional material. Alternatively, have the link open as a separate browser window which only partially overlays the current window - so the user can easily return.
15 - When linking to external sites from an instructional page, or any other copyrighted material, inform the user that the linked-to material is covered by a separate copyright.
The resulting web design is clear and potentially elegant, is
primarily text-based, has little or no extraneous adornment such
as irrelevant or distracting graphics, blinking text or animated
graphics. This respects the genuine needs of the user.
An excellent, free, online service for checking Web page
compatibility with HTML 4.0 (and previous versions) and with the
standards of particular browsers is 'Bobby' from the UK
disability organisation Center
for Applied Special Technology (http://www.cast.org/bobby/)
This service is one of the many online resources and Web software tools listed at: http://www.ncl.ac.uk/wwwtools/
For instance a page which relies on image-maps for navigation, rather than providing simple text-based hyperlinks as well, is inaccessible for those using a text-based browser.
Web browsers normally support graphic files using .GIF, .JPG and animated .GIF formats. However there are other proprietary graphic and sound formats which require the use of special software 'plug-ins' to the browser. Unless the use of these formats is necessitated by the educational application, they should not be used in VET sites. This includes MPEG video and Shockwave multimedia formats.
The situation with sound is less advanced than with still images: there is no single, widely accepted format for sound with today's Web browsers. Consequently, where sound is necessary, it should be in a format for which plug-in players are available for both major types of Web browser on both Mac and Windows machines. Hopefully in the near future, MP3 will meet this requirement - or better still be supported directly by the browser.
While frames are not a part of the HTML 3.2 specification, they are supported by both Netscape's and Microsoft's browsers and so are safe to use in Web-sites which must be accessible to most users. However frames can make navigation more difficult to understand, so they should only be used when they are vital to the communicative purpose of the site.
Netscape's JavaScript, an embedded scripting language for HTML which resembles Java, is supported by both major Web browsers, and so can be used when necessary. In contrast, Microsoft's VBScript is not supported by Netscape and so should not be used.
Both major browsers support Java 1.1, so this can be used today as a sophisticated means of programming interactive applications inside the browser. Java's transition from being a proprietary Sun standard to an open one under ISO, is not complete, but its future seems assured.
Microsoft proprietary Active-X technology performs some functions for which Java is intended. Active-X has other capabilities, especially for linking to programs running on the browser's machine. It is an application programming interface for the Windows operating system and is not applicable to Mac or Unix systems. Active-X will never be a Web standard which can be relied upon in terms of interoperability - so its use should be avoided unless there are compelling reasons.
Fonts are another are of incompatibility between browsers. Web designers who specify special fonts should do so in a way that a suitable font is likely to be found on Windows and Mac systems, using the browsers of both Netscape and Microsoft.
For the body text of web pages, the use of small or larger than normal font sizes should be avoided.
Cookies - short pieces of text which are stored by a server on the browser's hard disk of information, and which can later be sent to the same server automatically - raise some problems regarding privacy and security. They are typically intended to enable the server to provide some continuity within one or multiple browsing sessions by the same user, by storing potentially personal information in the cookies. However many VET users may be accessing the site from a computer which is not their own, and some browsers are intentionally configured by network managers to retain cookies in RAM for the current session, rather than on the hard disk. Cookies are potentially useful, but it would be desirable if sites continued to function properly with browsers which do not support them. Since cookie storage and retrieval is usually not seen or understood by users, any use of cookies to record personal information should be subject to the user's informed consent.
Many file formats are used by word-processing, page-layout, graphics and other kinds of programs. There is a need for people to view on screen and print these documents even though they lack the application program which created them. Ideally it would be possible to search the document and cut and paste text, data and graphics from it as well.
It is usually difficult or impossible to convert complex printed documents into HTML, but if this is possible, then HTML is the first choice for a 'portable document' format because it can be universally viewed, searched and printed with a standard Web browser. Over time, with HTML 4.0 - and its successor XML - HTML will become such a powerful language for screen and printed display that it is likely to supplant word-processing file formats in many applications.
The usefulness of HTML as a portable format is increased by
programs which convert it back to other formats more compatible
with word processing programs, such as Rich Text Format. An
MS-DOS program to achieve this - preserving a great deal of
layout information, including tables - is freely available at:
http://www.cena.dgac.fr/~sagnier/htm2rtf.htm
The most widely used word-processing program is Microsoft Word, and there are file-format incompatibilities between the various versions of this one program. It is common practice to avoid, where possible, the use of the latest version's file format - and to exchange files in Word 6/95 format. Rich Text Format is another alternative, but leads to large file sizes - especially if the document includes graphics. Microsoft has published its Word file format, but few companies have produced software which can read or write the full range of Word file formats.
By far the most widely used 'portable' document file format is Adobe's PDF format. This is based on Adobe's Postscript printer language, which is used in many office environments and in the production of virtually all books and magazines. Both Postscript and PDF are published, proprietary standards, so companies other than Adobe can write application programs which read or write PDF files.
The PDF format enables virtually any design which can be printed on paper to be made available on screen in a Web browser and to be printed on paper. PDF viewers as stand-alone applications and plug-ins for Web browsers are available without charge for a variety of computer platforms, including Windows, Mac, OS/2 and a variety of Unix systems including Linux.
PDF is a powerful method of communicating pages and large documents of great complexity, generally with the conversion being done semi-automatically. This means that documents which are primarily produced for hard-copy presentation - such as reports, books and catalogues - can easily be made available electronically. The resulting PDF files are relatively compact. However their contents are not as useable as they would be in HTML: they are harder to search and are not normally visible to Web based search engines. Capturing text and graphics from the PDF document can be more awkward than from an HTML or a word-processing file. With Adobe's Acrobat Reader, browsers can load and display PDF files within the browser window. PDF files can include video and sound and can contain links to external web material and targets so particular locations within the file can be accessed via a URL.
Metadata is information included in the header of an HTML document, but not normally displayed to the user - for the purpose of automating its inclusion in external indexing systems.
For instance, by viewing: http://www.edna.edu.au/EdNA/
and reading the first paragraphs of raw HTML source, by using
Netscape's "View: Source" command (or the same command
in Internet Explorer, which produces a less readable
representation), the impressive body of metadata in this file can
be seen.
While the low-level specification for metadata has long been part of the HTML specification, there are several higher level "languages" for expressing metadata, for instance the widely used "Dublin Core". For metadata to be effective in a particular field - such as VET educational sites within Australia, all educational sites within Australia or perhaps ideally all educational sites in the world, a particular metadata language must be standardised upon, and the structure of the metadata defined in a centralised way suitable for the indexing information which it is desired to convey. Such information is highly dependent on the nature of the field - for instance, educational material and course options require different metadata structure and content from genetic engineering.
There may be no need for VET to develop its own metadata standards. It will be necessary to ensure that VET web-site authors are aware of the extensive metadata work going on in the educational field within Australia, that they have the software and expertise to generate the appropriate metadata, and that they understand which web material should have valid metadata.
Arguably the web-pages made for password-protected access by learners in a particular class need not contain metadata since they will not be visible to the nation-wide metadata-based indexing structure - but perhaps metadata proponents would argue the opposite. It is vital that all material which represents the primary web-based description of available courses should include valid metadata.
In addition to metadata, certain aspects of the "outward facing" material of a VET institute's web site probably should be standardised to make them reasonably compatible across the nation. This is to make the course offerings of all Institutes appear in a reasonably compatible format to assist employers and potential students who are deciding whether to become involved in VET.
EdNA and VET metadata material is available at:
http://www.edna.edu.au/EdNA/genericpage.html?file=/edna/aboutedna/metadata/index.html
or by searching for "metadata" at the EdNA site.
A large number of technical standards underlie all Internet communications, such as the TCP/IP protocol, SMTP for email and HTTP for web access. It is not necessary to standardise on a particular version of HTTP, since there will be a smooth and automatic transition from the current 1.0 to the higher performance and downward compatible 1.1 as server and browser software is upgraded.
Those fields in which evolving or divergent technologies make it desirable to set a VET standard for 1999 - in some cases to be reviewed after six months, in early to mid 1999 - are:
[Home page] [Copyright statement] [Feedback]
Last modified on May 05, 1999.