Notes

Web Standards and Checklist

Page | 1
What are web standards and why should I use them?
1. Introduction
Tim Berners-Lees dream for his invention, the World Wide Web, is a
common space where users can share information to work together,
to play, and to socialize (The World Wide Web, A very short personal
history). As web developers, creating business, social, and
educational sites, we turn this dream into reality.
But in this period of tremendous growth, the Web needs guidance to
realize its full potential. Web standards are this guidance. These
standards help ensure that everyone has access to the information
we are providing, and also make web development faster and more
enjoyable.
Standards compliance makes it easier for people with special needs
to use the Web. Blind people may have their computer read web
pages to them. People with poor eyesight may have pages
rearranged and magnified for easier reading. And people using handheld devices can browse the Web just as easily as those using highend workstations.
As we will explain, there are also many practical reasons for
developers to be concerned with web standards. Search engines can
do a better job of indexing sites, for example. Using browser-specific
code often doubles or triples the work to create web pages, and
leaves a lot to be desired when new media are introduced. This
situation will only get worse without the sound direction of web
standards.
Some people fear that standards are limiting. In reality, they remove
much of the tedious labour involved in web development, and give
developers more time and more flexibility to be truly creative. They
are both open to future improvement and mindful of past technology.
Many uses of the Web, including some that are only dreamed of
today, will not be possible, or will be more difficult, without
widespread standards compliance. At the moment, there are systems
and software that are very common, seemingly close to universal,
but who knows what tomorrow will bring? Tying ourselves to the
control of any single company means limiting our future to the
fortunes and misfortunes which that one company can or will
provide. Maintaining universal standards will allow the Web to survive
while encouraging innovation to continue at its current pace.
Standards have so much to offer that we at The Web Standards
Project (WaSP) consider it necessary to help you learn more about
them. This document is merely a starting point; it will give you a solid
understanding of what standards exist, why they do, and why you
should care about them. Every time we create a piece of the Web, we
contribute to the common information space that is the Web. We can

build
Page it
| 2up, or we can add weight that will tear it apart. The choice
belongs to us; the consequences belong to everyone.
2 What are the standards?
2.1 W3C Standards
2.1.1 What is the W3C?
The World Wide Web Consortium (W3C) is an international industry
consortium dedicated to leading the Web to its full potential. Its
led by Tim Berners-Lee, the inventor of the Web. Founded in 1994,
the W3C has more than 450 member organizations
including Microsoft,America Online (parent company of Netscape
Communications), Apple Inc., Adobe, Sun Microsystems, and a
variety of other hardware and software manufacturers, content
providers, academic institutions, and telecommunications companies.
The Consortium is hosted by three research institutions MIT in the
US, INRIA in Europe, and Keio University in Japan.
2.1.2 What does it do?
The W3C develops open specifications (de facto standards) to
enhance the interoperability of web-related products. W3C
Recommendations are developed by working groups consisting of
Consortium members and invited experts. Working groups obtain
general consensus from companies and other organizations involved
in creating applications for the Web, and create Working Drafts and
Proposed Recommendations. These are then submitted to the W3C
membership and director, for formal approval as W3C
Recommendations. More information regarding this process and the
review stages can be obtained from the W3C website.
2.1.3 What are the W3C standards?
2.1.3.1 HTML 4.0 HyperText Markup Language
HyperText Markup Language (HTML) is widely used on the Web for
adding structure to text documents. Browsers interpret these
documents, representing the structure in media-specific ways to the
user. For example, visual browsers typically display
the strong element (<strong> </strong>) as bold text, while textto-speech readers might emphasize that text when pronouncing it.
With the help of Cascading Style Sheets (CSS) the author may define
how structural elements are to be represented, overriding the
browser defaults.
2.1.3.2 XML 1.0 Extensible Markup Language
Example of part of an XML document
<addressbook>
<entry>
<name>Bill Gates</name>
<email>bgates@microsoft.com</email>
</entry>
<entry>
<name>Marc Andreesen</name>

<email>marca@netscape.com</email>
Page | 3
</entry>
<entry>
<name>Jon S. von Tetzchner</name>
<email>jon@opera.com</email>
</entry>
</addressbook>
Extensible Markup Language (XML) is a markup language like HTML,
but instead of having a single, fixed set of elements, it allows you to
define your own or use a set made by someone else. It even allows
using multiple sets within a single document by using XML
namespaces.
Some applications of XML, such as XHTML and MathML, have already
become W3C Recommendations. Others are currently W3C Working
Drafts.
Style sheet standards, such as CSS and XSL, offer a variety of options
for specifying how XML elements are to be rendered. Standardscompliant support for direct rendering of XML is spotty in browsers,
so for presenting information to humans, HTML (or XHTML) with CSSdriven styling is the way to go. XML is mostly used for machine-tomachine communication today.
XML is more flexible than HTML, primarily because of the ability to
add your own elements and make your own structural systems. This
makes it an ideal format for the organization of large quantities of
data it is already in use in many databases and search engines.
2.1.3.3 XHTML 1.0, 1.1, and Modularization
XHTML 1.0 is a reformulation of HTML as an XML application. XHTML
1.0 can be seen as ideologically coming from HTML 4.01, and being
technically stricter because of XMLs influence.
XHTML will display in your browser identically to the equivalent
HTML. You might want to use XHTML if there is any chance youre
going to need to reprocess your content, for example to send it to a
PDA; XMLs stricter syntax rules make automatic processing of
XHTML much easier and cheaper than ordinary HTML.
Ideologically, XHTML 1.0 inherits the following general concepts from
HTML 4.01:
That presentation and document formatting should be separated
via style sheets
That documents should be made accessible
That documents should be internationalized
XHTML 1.0 also uses the model of three DTDs: Strict, Transitional,
and Frameset. This model originally emerged in HTML 4.0 and
followed through to HTML 4.01.
Some important technical practices from XML onto XHTML includes:
That all document types are declared via the correct DOCTYPE
declaration

Page
That
| 4 the structure of a conforming document contain the
DOCTYPE declaration, an html element with the XHTML
namespace declared, a head element including the title element,
and a body element
That all elements and attribute names are written in lower case,
and that all attribute values are quoted
That all non-empty elements (e.g. p, li) are properly terminated
with a closing tag
That all empty elements (e.g. br, hr, img) are properly terminated
with a trailing slash (<br />)
That documents validate against the DTD that is declared
For templates, please see Learn > Templates
XHTML 1.1 is made up of three primary parts:
The XHTML 1.0 Strict DTD (with minor modifications)
XHTML Modularization
The Ruby Annotation
If youd like to author documents in XHTML 1.1, you can do so in a
couple of ways. The first is by using the public XHTML 1.1 DTD. By
doing this, your work will be extremely structured because there are
virtually no presentational attributes in XHTML 1.1. The separation of
structure and presentation is complete here, and all of your
presentation work will go in a style sheet.
Another means of authoring documents in XHTML 1.1 is to tap into
XHTML Modularization. This is the breakdown of familiar components
of HTML and XHTML (such as text, tables, frames, forms) into discrete
chunks. You can then write your own DTD and use only those
components you require. This is extensibility in action, essentially
giving you, the web author, the opportunity to customize your
markup.
The Ruby Annotation is a special means of dealing with certain Asian
character annotations. Ruby falls under the work being done with
Internationalization.
2.1.3.4 CSS Cascading Style Sheets
Cascading Style Sheets (CSS) is a mechanism for changing the
appearance of HTML or XML elements, by assigning styles to element
types, self-defined classes of elements or individual instances.
Stylesheets can be used to consistently define the appearance of an
entire site. Following the introduction of CSS, the W3C recommended
that layout-specific features in HTML be phased out and replaced by
stylesheets, creating a simpler and more structural World Wide Web.
2.1.3.5 DOM 1 Document Object Model Level 1
The DOM allows the full power and interactivity of a scripting
language (such as ECMAScript, the standardized version of
JavaScript) to be exerted on a web page. (In programming terms, the
Document Object Model (DOM) Level 1 is an Application
Programming Interface (API) for interacting with web pages.) It gives
the scripting language easy access to the structure, content, and

presentation
of a document which is written in such languages
Page | 5
as HTML and CSS.
The DOM is compatible with future improvements in technology; it
will allow any scripting language to interact with whatever languages
are being used in the document. This standard will not only make it
easier to program dynamic HTML, but will also make adapting to
future Internet technology much less painful.
2.2 ECMA Standards
2.2.1 What is the ECMA?
The European Computer Manufacturers Association (ECMA) is an
organization officially founded in 1961 in order to meet the need for
standardizing computer operational formats, including programming
languages and input/output codes.
The ECMA is based in Geneva, Switzerland, near the headquarters of
the International Organization for Standardization (ISO) and
theInternational Electrotechnical Commission (IEC). In 1994, the
organizations name was changed to the ECMA European
Association for Standardizing Information and Communication
Systems, in order to reflect its broader range of activities.
2.2.2 What does it do?
The main role of the ECMA is to develop Standards and Technical
Reports in the area of information and communication technology. As
ECMA is an association of companies and not an official
standardization institute, they often collaborate with official national
or international institutes.
ECMA Standards have been accepted as a base for international and
European standards. So far more than 270 ECMA Standards and 70
Technical Reports have been published.
Of these standards 85 have been accepted as international standards
by the International Organization for Standardization (ISO). In
addition, 25 have been accepted as European standards by
the European Telecommunications Standards Institute (ETSI).
2.2.3 What are the ECMA standards?
2.2.3.1 ECMAScript (standardized JavaScript)
ECMAScript is a standardized scripting language, based largely
on Netscapes JavaScript and Microsofts JScript. The ECMAScript
standard is defined by ECMAs Technical Committee 39 (TC-39).
The main use of ECMAScript, which is an object-based language, is to
manipulate the objects in web pages which are specified by
theDocument Object Model (DOM). These objects (effectively, the
elements which make up web pages, or the web pages as a wholes)
can then be added to, deleted, moved, or have their properties
changed. This lets web developers implement such effects as
animated text, graphic roll-overs, and pages that change based on
user input without having to be reloaded.
The current ECMAScript specification is ECMA Standard ECMA262, ECMAScript Language Specification, 2nd edition.
3 What are the advantages of using web standards?

3.1
Accessibility
Page
|6
3.1.1 To software/machines
Complying with web standards can give your web pages greater
visibility in web searches. The structural information present in
compliant documents makes it easy for search engines to access and
evaluate the information in those documents, and they get indexed
more accurately.
Because use of web standards makes it easier for server-side as well
as client-side software to understand the structure of your document,
adding a search engine to your own site becomes easier and gives
better results.
Standards are written so that old browsers will still understand the
basic structure of your documents. Even if they cant understand the
newest and coolest additions to the standards, theyll be able to
display the content of your site. The same, of course, applies to
robots systems that collect information from your site on behalf of
search engines and other indexers.
Compliant code gives you the opportunity of validating your page
with a validation service. Validators process your documents and
present you with a list of errors. This makes finding and correcting
errors a lot easier, and can save you a lot of time.
Compliant documents can easily be converted to other formats, such
as databases or Word documents. This allows for more versatile use
of the information within documents on the World Wide Web, and
simplified migration to new systems hardware as well as software
including devices such as TVs and PDAs.
3.1.2 To people
Accessibility is an important idea behind many web standards,
especially HTML.
Not only does this mean allowing the web to be used by people with
disabilities, but also allowing web pages to be understood by people
using browsers other than the usual ones including voice browsers
that read web pages aloud to people with sight impairments, Braille
browsers that translate text into Braille, hand-held browsers with
very little monitor space, teletext displays, and other unusual output
devices.
As the variety of web access methods increases, adjusting or
duplicating websites to satisfy all needs will become increasingly
difficult (indeed, some say its impossible even today). Following
standards is a major step towards solving this problem. Making your
sites standards-compliant will help ensure not only that traditional
browsers, old and new, will all be able to present sites properly, but
also that they will work with unusual browsers and media.
Some consequences of ignoring standards are obvious: the most
basic consequence is that you will restrict access to your site. How
much business sense does it make to limit your audience to only a
fraction of those who wish be a part of it? For a business site, denying
access to even small portions of a target audience can make a big

difference
Page | 7 to your profit margin. For an educational site, it makes
sense to allow access not only to affluent, able-bodied schoolchildren with graphical browsers, but also to children in regions with
poorly-developed infrastructure who are best served by text-only
browsing, or disabled students using specialized browsers.
The same principle applies to all types of websites while straying
from the standards and taking advantage of browser-specific features
may be tempting, the increased accessibility which comes from
standards-compliance will lead to far greater rewards in the long run.
3.2 Stability
Most web standards are generally designed with forward- and
backward-compatibility in mind so that data using old versions of
the standards will continue to work in new browsers, and data using
new versions of the standards will gracefully degrade to produce
an acceptable result in older browsers.
Because a website may go through several teams of designers during
its lifetime, it is important that those people are able to comprehend
the code and to edit it easily. Web standards offer a set of rules that
every Web developer can follow, understand, and become familiar
with: When one developer designs a site to the standards, another
will be able to pick up where the former left off.
4. Conclusion
As web developers, we are constantly trying to address the problem
of inconsistencies between the renderings of web pages by different
browsers and browser versions. This necessitates either timeconsuming double/multiple coding, or coding for a single browser
which makes it harder, if not impossible, for some of the public to use
the site. This situation will be made even worse with the advent of
additional hardware and software which will be able to browse the
Web, such as telephones, pagers, and PDAs.
Web standards are not arcane laws decreed by ivory-tower
organizations. As we have described, the standards are for the most
part decided by representatives of the same people who use them
browser makers, web developers, content providers, and other
organizations.
Writing web pages in accordance with the standards shortens site
development time and makes pages easier to maintain. Debugging
and troubleshooting become easier, because the code follows a
standard. No longer do you have to worry about the coding and
maintenance for several versions of code that are supposed to
accomplish the same presentation. One version of your site, and that
is it.
The universal adoption of web standards is becoming of paramount
importance. The mission of The Web Standards Project is to make the
Web a better place, for developers and for end-users, by encouraging
browser and web page editor makers to follow the standards in their
applications. This effort will be greatly helped when web

developers
use the standards as a matter of course, and insist that
Page | 8
generators and renderers of their code comply with the standards.
The reasons we have given should give you, the web developer,
plenty of incentive to begin using standards, and also plenty of
ammunition with which you can encourage your place of business
and fellow developers to use those standards.
Help make the dream a reality.
Web Standards Project Developer Education
Committee: Stephan Nedregaard (coordinator), Kynn Bartlett, Gail
T. Cohen, Jens Edlund, Nick Finck, Tomas Fjetland, Peter Fleck,
Markus Gut, Holger Maier, Julian Missig, Laura Mollett, Randy Piatt,
Lewis A. Shadoff, Juergen Steinwender, Bart Szyszka, Matthew
Thomas, Dane Weber
Updated 02-27-2002 by Molly E. Holzschlag and Shirley E. Kaiser of
WaSP LEARN Committee.

Page | 9

HTML Standards
Concepts
Why We Need Standards
The World Wide Web, invented in the early 1990's, made it possible to
distribute documents globally without worrying about what kind of
computer or software the user had (as long as the user had an Internetconnected computer and a Web browser, of course). The way the Web was
defined, the syntax of HTML was independent of computer type, and each
kind of Web browser created was meant to display an HTML file correctly.
At least this was the dream.
The reality is that during the 1990's, economic and cultural forces
muddied the waters. Some people made Web browsers that recognized
HTML elements that had not been accepted as standards. Some
companies created Web browsers fashioned to recognize companyspecific (proprietary) HTML elements and attributes of elements. Some
companies created Web browsers that recognized proprietary elements
and attributes that were in conflict with the proprietary elements and
attributes of other companies.
Without standards, the World Web Web becomes fragmented. When you
have to worry about what kind of browser you are using in order to see
Web content, you're experiencing a problem that the Web was originally
invented to solve.
We need standards to make sure that all Web content is viewable by many
different kinds of Web browsers--and not just the Web browsers of today,
but the handheld devices, cell phones, or other Net devices that may be
invented in the future.
Using standards also lowers HTML production and maintenance costs. By
educating HTML implementors in a fixed set of standards, you can reduce
training time, increase the accuracy of implementation, reduce display
errors, improve the appearance of Web pages, and make it possible for
further maintenance with the least amount of hassle.
I advise that you stick to HTML standards and validate your HTML files so
that your Web pages are most likely to be satisfactorily displayed in the
widest range of browsers and devices. The organization that coordinates
HTML standards is the World Wide Web Consortium (W3C). You should

bookmark
Page | 10their site as the best and most authoritative source for HTML
standards. See also the Web Standards Project.
Key things to keep in mind:
1. HTML standards help you reach the widest possible audience.
2. HTML is now specified as XHTML 1.0 (HTML + XML = XHTML). The
expressiveness of XHTML 1.0 is quite impressive and complex.
However, "plain old" HTML is still usable and quite useful.
3. There are many technologies that are associated with HTML
because they are used on a Web page or in conjunction with HTML.
But these technologies are not HTML:
o CGI (Common Gateway Interface)
o Java
o JavaScript (JavaScript is also not Java)
o Dynamic HTML (DHTML)
o XML (Extensible Markup Language)
o A variety of other emerging technologies.
4. Sometimes you are going to have to break the rules and use nonstandard syntax for good reasons. Try to keep this to a minimum.
How to Follow HTML Standards
1. Identify which version of HTML you are using in your document
through the DOCTYPE line at the top of your file. For documents
that use only HTML 2.0 features (like hello, world), you could use
this DOCTYPE statement:
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
For documents that use HTML 3.2 features, you could use this
DOCTYPE statement:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
There are other DOCTYPE statements that you will need to use for
other versions of HTML. For example, to use HTML 4.01 features
and a "loose" conformance to syntax standards, you could use this
DOCTYPE statement:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

PageYou
| 11use another DOCTYPE statement when you create an XHTML

document. For example, look at this simple XHTML document and

use your browser to view its source to see its DOCTYPE statement.
See the W3C site for more information on document types and
DOCTYPE statements.
The important thing to remember is that a DOCTYPE statement is
essential to assisting validation software in checking your
document.

2. Use tools that support standards. In particular, install and use the
Tidy program or Tidy GUI on your computer.
3. Use validation to check the syntax of documents you create.
4. Refer to W3C for technical and syntax information.
Having correct HTML syntax helps your Web site's usability in the widest
range of browsers. However, don't become a "syntax snob"--one who
proudly verifies and tweaks HTML pages to perfect syntax, yet ignores the
meaning and content of those pages.
Consider these HTML tips when you are making Web pages.
Exercise: Check a Web document
Use validation to check the syntax of documents you have created.
Validating a Web Document
You can detect and diagnose HTML syntax errors in your document by
using a validator. First, make sure you have an
appropriate DOCTYPE statement (and, optionally, a character encoding
statement) in your document. Then:
1. Go the the Web page http://www.htmlhelp.com/tools/validator/
2. Enter the URL of your assignment in the box which is labeled URL:
3. Make sure that the checkbox for "show input" (second checkbox
below the URL: box) is checked
4. Click on "Validate it!"
5. Fix the syntax errors you have. A good idea is to start with the first
error that you have, fix it, and then re-validate. Repeat until you
have no syntax errors.
6. If you want, you can use the Tidy service to help you. See The HTML
Toolbox under "Utilities." Tidy can help you diagnose HTML syntax
errors, but it is not a validator. Any output you get from Tidy should
be run through the validator again

Page | 12

List
of well-known
document mark-up languages
Page
| 13

HyperText Markup Language (HTML) the original markup language

that was defined as a part of implementing World Wide Web, an ad hoc
defined language inspired by the meta format SGML and which inspired
many other markup languages.

Extensible HyperText Markup Language (XHTML): HTML

reformulated in XML syntax.

XHTML Basic a subset of XHTML for simple (typically mobile,

handheld) devices. It is meant to replace WML, and C-HTML.

XHTML Mobile Profile (XHTML MP) a standard designed for

mobile phones and other resource-constrained devices.
Mathematical Markup Language (MathML)

Rich Text Format (RTF) Microsoft format for exchanging documents

with other vendors' applications. (It is not really a markup language, as
it was never meant for intuitive and easy typing.[1][2])
Scalable Vector Graphics (SVG)

TeX, LaTeX a format for describing complex type and page layout
often used for mathematics, technical, and academic publications.
Extensible 3D (X3D)

Metalanguages

Standard Generalized Markup Language (SGML) a standard pattern

for markup languages to which HTML and DocBook adhere.

Extensible Markup Language (XML) a newer standard pattern for

markup languages; a restricted form of SGML that is intended to be
compatible with it.

]Lesser-known document markup languages

(including some lightweight markup languages)
ABC music notation - markup language for music scores in pure text.

[3]

 PageChemical
Markup Language (CML)
| 14

Compact HyperText Markup Language (C-HTML) used for some

mobile phones.

Computable Document Format - used for interactive technical

documents.

ConTeXt a modular, structured formatting language based on TeX.

Crossmark common markup with macros.

Darwin Information Typing Architecture (DITA)

DocBook format for technical (but not only) manuals and

documentation.

eLML eLesson Markup Language: create eLearning content

Encoded Archival Description (EAD)

Enriched text for formatting e-mail text.

Generalized Markup Language (GML)

Guide Markup Language (GuideML) used by the Hitchhiker's

Guide site.[4]

Handheld Device Markup Language (HDML) designed for

smartphones and handheld computers.

Help Markup Language (HelpML)

Hypermedia/Time-based Structuring Language (HyTime)

HyperTeX for including hyperlinks in TeX (and LaTeX) documents.

Information Presentation Facility (IPF) is a system for presenting

online help and hypertext on IBM OS/2 systems. It is also the default
help file format used by the cross-platform fpGUI Toolkit project.

LilyPond a system for music notation.

LinuxDoc used by the Linux Documentation Project.

Lout a document formatting functional programming language,

similar in style to LaTeX.

 PageMaker
| 15 Interchange Format (MIF)

Markdown - simple plaintext markup popular as language of

blog/cms posts and comments, multiple implementations, used to
generate HTML.[5]

Microsoft Assistance Markup Language (MAML)

Music Encoding Initiative (MEI)

Music Extensible Markup Language (MusicXML)

Open Mathematical Documents (OMDoc)

OpenMath a markup language for mathematical formulae which

can complement MathML.

Plain Old Documentation (POD) a simple, platform-independent

documentation tool for Perl.[6]

Xupl - a C-style equivalent to XML.

Remote Telescope Markup Language (RTML)

reStructuredText (reSt) - plaintext platform-independent markup

used as Python libraries documentation tool, multiple output formats
(HTML, LaTeX, ODT, EPUB, ...)[7]

Retail Template Markup Language (RTML) e-commerce language

which is based on LisP.

Revisable-Form Text (RFT) part of IBM's Document Content

Architecture to allow transfer of formatted documents to other
systems.

S1000D international specification for technical documentation

related to commercial or military; aerospace, sea or land; vehicles or
equipment.

Scribe Brian Reid's seminal markup language

Script Early IBM markup language on which GML is built.

SKiCal - a machine-readable format for the interchange of enhanced

yellow-page directory listings.

Text Encoding Initiative (TEI) Guidelines for text encoding in the

humanities, social sciences and linguistics.

 PageTexinfo
GNU documentation format.
| 16

troff (typesetter runoff), groff (GNU runoff)

Wikitext used in Wikipedia, MediaWiki and other Wiki installations.

Wireless Markup Language (WML), Wireless TV Markup

Language (WTVML)

Extensible Application Markup Language (XAML) XML based user

interface markup language

Z Format an open, document and typesetting language inspired by

TeX.[8]
Office document markup languages

Compound Document Format

Office Open XML (OOXML) open standard format for office

documents:
SpreadsheetML spreadsheet language, part of Office Open

XML.

PresentationML presentations language, part of Office Open

XML.

WordprocessingML wordprocessing language, part of Office

Open XML.

Microsoft Office 2003 XML formats, predecessor of Office

Open XML.
OpenDocument (ODF) open standard format for office documents.

OpenOffice.org XML predecessor of OpenDocument.

ReportML Report format language originating from Microsoft

Access. (not a part of Office Open XML (yet))

Uniform Office Format (UOF) open format for office documents,

being harmonised with OpenDocument.

See
also
Page
| 17

Comparison of document markup languages

Comparison of Office Open XML and OpenDocument

Lightweight markup language

References
1.
2.

^ RTF Pocket Guide by O'Reilly Media, retrieved 2010-03-13

^ Sean M. Burke (2003-07). "RTF Pocket Guide". Retrieved
2010-03-13.

3.

^ http://abcnotation.com/wiki/abc:standard

4.

^ h2g2

5.

^ http://daringfireball.net/projects/markdown/

6.

^ http://perldoc.perl.org/perlpod.html

7.

^ http://docutils.sourceforge.net/rst.html

8.

^ http://z.departure.dk/

Page | 18
Markup
Languages List

1. Application Markup Language (AppML)

50. Instrument Markup Language (IML)

2. Architecture Description Markup

Language (ADML)

51. International Development Markup

Language (IDML)

3. Artificial Intelligence Markup Language

(AIML)

52. Java Speech Markup Language

(JSML)

4. ASN.1 Markup Language (AML)

53. Karst Markup Language (KML)

5. Astronomical Instrument Markup

Language (AIML)

54. Koala Bean Markup Language

(KBML)

6. Astronomical Markup Language (AML)

55. Lambda Markup Language (LML)

7. Automatic Site Markup Language

(ASML)

56. Learning Material Markup Language

(LMML)

8. Bean Markup Language (BML)

57. Legal Extensible Markup Language

(LegalXML)

9. Better Markup Language (BML)

58. Liturgical Markup Language (LitML)
10. Bibliography Markup Language
(BibML)
11. Bioinformatics Sequence Markup
Language (BSML)

59. Log Markup Language (LOGML)

60. Mail Markup Language (MML)
61. Maker Markup Language (MML)

12. BIOML - BIOpolymer Markup

Language
13. Board Game Markup Language
(BGML)
14. Business Rules Markup Language
(BRML)

62. Market Data Markup Language

(MDML)
63. Mathematical Markup Language
(MathML)
64. Meaningful Text Markup Language
(MTML)

15. Comics Markup Language (ComicsML)

65. Medical Markup Language (MML)
16. Chemical Markup Language( CML)
17. Claris Dynamic Markup Language
(CDML)

66. Mind Reading Markup Language

(MRML)
67. Modest Markup Language (MML)

18. DARPA Agent Markup Language

(DAML)
19. Description Logic Markup Language
(DLML)

68. Multimedia Retrieval Markup

Language (MRML)
69. Music Markup Language (MML)

Page | 19

20. Directory Services Markup Language

(DSML)

70. Outline Processor Markup Language

(OPML)

21. Document Template Markup Language

(DTML)

71. Pet Name Markup Language (PNML)

72. Procedural Markup Language (PML)

22. Dynamic Hypertext Markup

Language (DHTML)

73. Printing Industry Markup Language

(PrintML)

23. Dynamic Markup Language (DML )

24. E-business eXtensible Markup
Language (ebXML)

74. Question and Answer Markup

Language (QAML)
75. Quest Markup Language (QML)

25. Earth Science Markup Language

(ESML)
26. Environmental Markup Language
(EML)

76. Relational-Functional Markup

Language (RFML)
77. Research Information Exchange
Markup Language (RIXML)

27. eXtensible Application Markup

Language (XAML)

78. Rule Markup Language (RuleML)

28. eXtensible rights Markup Language

(XrML)

79. Security Assertion Mark-up

Language (SAML)

29. eXtensible Telephony Markup

Language (XTML)

80. Security Services Markup Language

(S2ML)

30. eXtensible Graph Markup and

Modeling Language (XGMML)

81. Simple Markup Language (SML)

31. eXtensible Hypertext Markup

Language (XHTML)
32. eXtensible Markup Language (XML)
33. Farleden Dynamic Markup Language
34. Field Data Markup Language (FDML)

82. Simulation Module Markup Language

(SiMMaL)
83. Spacecraft Markup Language (SML)
84. Standard Generalized Markup
Language (SGML)
85. Synchronization Markup Language
[SyncML]

35. FileMaker Dynamic Markup Language

(FDML)

86. Synthesis Markup Language

36. Financial products Markup Language

(FpML)

87. Theological Markup Language

(ThML)

37. Financial Services Markup Language

(FSML)

88. Transaction Authority Markup

Language (XAML)

38. Forms Data Markup Language (FDML)

89. Trading Partner Agreement Markup

Language (TPAML)

39. Form Document Markup Language

(FDML)

90. Transaction Authority Markup

Page | 20

40. Forms Definition Markup Language

(FDML)
41. Forms Markup Language (FML)
42. Gene Expression Markup Language
(GEML)
43. Geometry Description Markup
Language (GDML)

Language (XAML)
91. Turing Machine Markup Language
(TMML)
92. Tutorial Markup Language (TML)
93. Universal Rule Markup Language
(URML)

44. Geography Markup Language (GML)

94. Virtual Reality Markup Language

(VRML)

45. Handheld Device Markup Language

(HDML)

95. Voice Extensible Markup Language

(VoiceXML)

46. Hypertext Markup Language (HTML)

96. Why Markup Language (YML)

47. Human Markup Language (HumanML)

97. Wireless Markup Language (WML)

48. Human Resources Markup Language

(HRML)

98. Yet Another Markup Language

(YAML)

49. ICAAP eXtended Markup Language

(IXML)
50. Image Markup Language (IML)
51. Instrument Control Markup Language
(ICML)

Page | 21

How to Build a Web Page: Requirements

This was originally published December 2009 in SES Magazine.
Items to Include in Detailed Requirements
Documentation
Requirement

Acronym

Accounts for

User interface
requirements

UIR

includes IA, design, fonts,

images

Search engine
requirements

SER

SEO, PPC, SEM, and linking

Social media
requirements

SMR

blog, forums, social sites

Usability and accessibility

requirements

UAR

usability heuristics, mobile,

Section 508, PAS 78

Business and Functional Requirements First

Typically, the requirements gathering phase of a Web design is performed by your team as you gather
around a whiteboard or conference call. The leading business requirements are laid down first. Is the
site an e-commerce site, directory, blog, or informational site? What do we want the site to do, and
why? What do we need to create a successful Web site?
Top-level requirements are called parent requirements. They anchor the site's plans. Your team
discusses all the goals, no matter how big or small, for the site. There may be several business
requirements, such as "provide services," "get sales leads," or "to inform." Parent requirements are
broad strokes that are later more fully defined.
Along with business requirements, the other set of parent requirements are functional requirements.
This is your programmers' domain. Functional specs refer to technical, server, and application issues,
and are typically derived from use cases, mental models, and user personas. Functional requirements
determine guidelines for browsers, operating system, accessibility, bandwidth, performance, platform,
mobile use, and programming choices.
The process of gathering information at the start of your project helps many members of your team
throughout the development cycle. This includes those who create the information architecture, those
who do QA testing, and the sales department. A final requirements document can be used to create
test cases to ensure every requirement is met.
The Forgotten Requirements
Let's look at this example of business requirements for an e-commerce Web site:

BR4.0 Sell online

BR4.1 Shopping cart

BR4.1.1 Custom cart

BR4.1.2 SEO-friendly

BR4.2 Marketing

BR4.2.1 User-generated content, social media, weekly sales, coupons, online accounts, etc.

| 22
ThePage
process
of writing down all the desired elements can be a painstaking exercise. In the example,
everything is traceable back to "BR4.0 Sell online." The shopping cart is intended to help, but there is
a requirement for a search engine-friendly one. One option is build a custom cart. If that is agreed
upon, a separate set of functional requirements are written just for the cart. Every requirement and
every guideline is traceable to a parent goal. Any time someone wants something added that can't be
traced to a business requirement, it is not included.
Very few companies consider marketing or usability at the earliest stages of development. But what
about "BR4.2 Marketing" from our example? To meet the user-generated content needs, team
members will need to confer with those who are determining functional specs, which include the kinds
of software applications that can be used for comments and customer ratings.
Organic search engine optimization (SEO) and search engine marketing (SEM) are not typically
applied to requirements documentation, but they should be, so that certain techniques - such as how
to structure title tags or guidelines for link labels - are worked out in advance. A business requirement
may be "BR6.0 Be found in search engines."
Most site owners take this for granted and don't begin the process. A requirement for SEO can be
broken down into functional requirements for on-page optimization as well as details like robot.txt.
When every piece is documented, anyone can go through the site at any point to test for compliance.
Critical Breakdown
When approaching the discipline of requirements gathering, it's imperative that all stakeholders from
each area of the development process are communicating. Of equal importance is testing during the
development phase to make sure requirements are met and there are no conflicts.
For example, a search for "leather fringe boots" displays several search results. One result is a boot
with no fringe. Did the page have incorrect content on it? Or, was it the right boot but the wrong
images? Why were the photos not showing the boot properly?
A few things could have occurred. There may not have been a requirement for specific title tags and
page titles. There may not have been a requirement that all images be shown at all angles. It's likely
that there is no requirement that covers searcher behavior. This is closely tied to usability. A cohesive
document will spell out how to write content for searchers, how to optimize for engines, and how to
display media to sell a product.
Requirements documentation is a group exercise. Who is the site for? How will you meet user
expectations, including searchers? Written Web site guidelines, based on the site's requirements,
determine design consistency, site maps, and mockups.
If your main goal is to sell products, do you showcase some of them on your home page? Are product
pages optimized for search engines as landing pages? Search engines are unable to deliver site
pages the way you want them presented without first including SEM into the overall requirements
documentation. This means that every element on the page has to meet criteria traceable back to
business and functional requirements, as well as meeting supportive requirements such as marketing
and SEO.

Page | 23- Content Management System Requirements Checklist

Example

(Check whichever is applicable)

Web Development Capabilities

Development and Quality Assurance

Must support a develop, stage and deploy framework

Must support branching to allow for co-development of
parallel site
Must support the concept of separate user environments
for development
Must support concurrent development of assets (e.g.
asset locking)
Must be an open architecture
Must provide a way for contributors to QA their own work
Must provide a way to snapshot current development for
standards review.
Must provide private work areas for non-disruptive Web
development
Must have ability to compare a file to any of its previous
versions
Must provide for commenting
Must have HTML merge capability
Must have global search and replace
Must have automated content scheduling (for both
publishing and archiving)

Asset Support Capability

Must be able to support database assets

Mandator
y

Highly
Desirable

Desirable
(but
Optional)

Pageto| automatically
24
Must be able
sync database and file
system content
Must support existing file system assets to eliminate
content retrofit
Must support rules-based search against all meta-tagged
assets
Must fully support streaming media
Must provide portal-style in-line asset commands for
personalisation
Must have the ability to deliver content in different
formats (ie PDF, word, audio, video)

Workflow
Must have a clearly defined procedure that ensures that
records are identified and captured into a recordkeeping
system
Must support designated agency approvals processes
Must contain a graphical user interface to build workflows
Must support iterative loop backs for rejected changes
Must support flexible workflow definition to capture
existing process
Must support task-based workflow (ie creation, editing,
approval)
Must support metadata integration for configurable
smart workflows
Must support modifiable task attributes
Must support nested workflows
Must support rules-based Workflow Registration
Must allow users to view tasks assigned to them
Must have the ability for Managers to monitor tasks and
initiate follow-ups
Must allow automated notifications of tasks to be

Page | 25
performed

Project Management
Must support parallel development streams
Must support instant creation of separate development
environment.
Must support reporting via standard reports or
customisable reports
Must support workflow tracking and monitoring

Versioning and Rollback Capability

Ability to version complete sites not just components
Ability to rollback to previous version of sites
Ability to log and monitor changes to site components
Ability to rollback to previous version of site components
Must display status of files and folders
Must have change tracking and the creation of audit trails

Templating
Must support content for re-use
During content entry, contributors must be able to
manipulate content elements
Must be able to support customised components within
the page generation engine
Ability to standardise content according to business rules
Must separate Form from Content
Must support pre-generated pages for increased
scalability and performance
Must support on-the-fly pages

Pagethe
| 26
Must support
nesting of templates
Must support variable binding
Must have metadata management facilities
Must support the ability for users to add to templates
Must provide browser based GUI
Must provide URL-Based Templating

Deployment Capability

Must provide high security during deployment

Must be able to flexibly re-map directories during
deployment
Must support transactional deployment for rollback for
both database and filesystem assets
Must be able to deploy files, databases and code
synchronously
Must be able to schedule automatic deployment to
production server
Must be able to move database tables from staging to
production
Must support incremental and transactional deployment
for database and filesystem assets

Third party Integration and Customisation

Must support industry standard authoring tools

Must supports all app servers & e-Commerce engines
Must be able to customise application for integration
Must support automatic link checking
Must support automated split-up of long documents
Must have full attribute and content searching
Open to any personalisation technology

Pageto| leverage
27
Must be able
existing enterprise resources
through seamless process and application integration

Reliability, Availability, and Security

Must support 128-bit encryption, peer to peer

authentication
Must contain functions to make the most efficient use of
available storage space
Must support load balancing, system failover and session
management capabilities
Must support role-based privileges in development
Must support reporting (including usage analysis)

User Interfaces

Must be able to support seamless integration with

Microsoft Office Tools (Word, Excel, etc.) and Lotus
Notes applications
Must have an easy to use interface with user id,
password and role
Users must have the ability to personalize their interface
Must allow non-technical contributors to contribute with
minimal training
Must support a file system interface - supports any front
end editing tool
Must be scalable to meet growing volume of users
Must have Agency platform compatibility
Must have Agency browser support