Wendell Piez was born in Frankfurt, Germany, and spent his early years in Central Asia and the Far East. Educated at Yale and Rutgers, he has a Ph.D. in English. He has been working with markup languages since 1994. At Mulberry Technologies since 1997, he has designed and implemented XML-based systems both for clients and for internal use. A frequent contributor to XSL-List, he also sits on the Executive Council of the Association for Computers and the Humanities.

What does it mean to migrate a web-based publishing system from HTML to XML? It turns out that this question has no simple answer. Although XML is often -- misleadingly -- described as the Next Big Thing after HTML, as HTML's successor, or even as its competitor, in fact the choice between HTML and XML is not really best understood as "either/or". Many XML-based systems, if they publish to the web, will still use some kind of HTML as a "front end", even while the data in the back is in XML.

We are commonly faced with the proposition that, in order to gain this or that capability for our site, we should move to XML. In order to understand what such migration will mean, it helps to have a grasp of some of the technical issues involved. Bringing a critical eye to the markup itself reveals immediately -- even to a neophyte or non-expert -- how the data may be put to use and what kinds of applications it is capable of supporting. Accordingly, this presentation proceeds by breaking the problem down into several separate cases, each of which we have illustrated with a simple example. After briefly noting what the actual relation is between XML and HTML as standards, we will look at each of these cases in turn. Gaining a sense of what the differences are between the cases, and what the challenges are of migrating data from one approach to another, will clarify the alternatives, along with their advantages and costs.

In untangling the complexities of what it means to migrate from HTML to XML, and what issues it raises, there are some important topics that we will not address. We will not consider strategic questions such as why do this in the first place: the assumption is that we can take for granted XML's advantages for data longevity, reusability, and so forth. Likewise, we will not be considering architectural or implementation issues such as which server technology to use, whether to store our data in a database or a file system, how to organize and administer the data, whether to do necessary processing in batch mode, or dynamically on the server, or on the client, etc. etc. These issues are important; and a very useful and interesting paper could be written describing how to approach them and the various dependencies these problems have (since the answer to any of these questions seems to be, "it depends"): but that paper is not this one. Instead, we will be looking at the formats themselves, to assess their differing capabilities as underlying technologies.

Organization

Background
- HTML
- XML
- Differences between HTML and XML
Conversion Cases
- HTML to Well-formed XML
- HTML to structured HTML-XML
- HTML to XHTML
- HTML to Valid XML
  - Structural Markup
  - Content-based Markup

What is HTML?

Document (web page) layout "language"
Link specification "language"
A set of tags
- Mark start of document component
- Mark end of component (maybe)
- Name a hyperlink

What do HTML Tags Say They Do?

Link specific parts of your document (<a>)
- To other places in your document
- To sources outside your document
Format parts of your document (<b>, <h1>, <hr>, <font>)
Mark the structure of your document (<div>, <p>, <body>)
Describe your document's content (<abbr>, <address>)

HTML Tags Really Do Nothing

Tags have no inherent meaning
Browsers do things based on tags
- Tags built into browser
- Browser chooses tags to implement (<blink>)
- Every browser may do differently

What is XML?

A W3C recommendation that provides:
- Description of a data format
- A data modeling language
The use of the XML data format in an application (e.g. a browser)
A "meta" language for:
- Creating markup languages
- Using markup languages

XML Documents

In XML jargon, your data (no matter what form) is called a document
Examples:
- invoice
- journal article
- topic in a help system
- database load file
- email message

XML Markup Identifies Document Components

Content of the data
Structure of the document
Value-added information
- Location and Navigation
- Metadata
Rendering/Processing information (presentation and formatting)

Content Markup

What type of information is this?

Part number
Environmental impact
City, state, zip code
Question, answer
Methodology section
Hardware platform
Error message and error code

Structure Markup

What part of the document is this?

Email header
Paragraph
Title
Figure
Table
Signature block
List

"Location or Navigation" Information

Added to text to make it more functional, useful or manageable

Hypertext links
Cross-references
Indexing terms

Metadata (Data about the Data)

Bibliographic information
Revision or version
Status and workflow tracking information
Data source
Editor's or reviewer's comments
Abstracts, teasers, cataloging data

Rendering/Processing Markup

How text should print, display, or behave

Position of graphics on the page
Line breaks in titles
Iconization
Visual or auditory highlighting (sometimes a word is bold just because the author said so)

HTML is (Implicitly) Formatting Markup

H1-style, H2-style
skip a line <p>

Many HTML tags sound like generic elements (<emph>, <p> for paragraph, <li> for list item) but they are abused to create the desired display. For example, words that aren't "definition terms" are tagged <dt>.

HTML has codes for:

A little bit of metadata
One type of location tag

XML Tags Really Do Nothing

Tags still have no inherent meaning
Tags could be built into special-purpose software
General-purpose XML software won't build in tags
What general-purpose XML browsers and processors do is based on
- Tagging in the document PLUS
- Stylesheet, behavior sheet, output or processing specification

Differences Between XML and HTML

HTML	XML
Fixed set of tags	User-made tags (infinite variety)
Flat	Structured (nested)
Total freedom (at your own risk)	Draconian error handling
***Case insensitive	***Case sensitive
***End tags (mostly) optional	***All start and end tags required
***Syntax loose	***Syntax strict
One linking tag/One link type	Any element may be a link/Many types and roles for links
Tags built into browser	Tags and specification input to processor

XML has no Pre-defined Tags

User communities make up tag sets
Tags match user needs/language
Structural tags are specific to a class of documents (<part>, <chapter>, <header>, <section>)
Content tags are domain-specific (<part_number>, <methodology>, <person_name>, <job_function>, <zip>)

HTML Markup is "Loose"

Most tags say where something starts (<h1>, <h2>, <h3>, <p>)
A few tags say where something ends
- Some you need: </b>
- Some you don't: </tr>, </p>

XML Markup is Strict

Tags indicate the beginning and end of all elements

. . . closing tags are required .

HTML Structure is Flat

Title , followed by
Paragraph , followed by
Heading Level 1 , followed by
Paragraph , followed by
Paragraph

(Most word processors and desk-top publishing applications are like this, too)

XML Makes Nested Structures

Tags identify the start and end of each structure, not simply the start of a format
A document might contain:
- Title followed by
- Paragraph followed by
- Section , containing
  - Title followed by
  - Paragraph followed by
  - Paragraph followed by ...

Structured Documents Contain Nested, Retrievable Objects

Advantages of Structured Documents

Store, retrieve, and reuse objects
Limit a search to within an object (or exclude an object from a search)
Handle at any level of granularity (detail)
Automatically derive tables of contents, lists of figures, indices, etc., from named structures
Cut and paste complete structures
Manage and manipulate at any level

An XML Document is a Tree

Nested document structure can be thought of as a tree
Top level element is the "root"
Only one root (<html></html>)
All elements inside that root NOT <html></html><body></body><img></img>

Tree Structure Indicates Nesting

HTML Error Handling: Permissive

Early design decision
If you don't know what a tag or structure is, ignore and keep going
Recover at all costs, even if you skip stuff
Result of this
- Browser wars
- Competition on tag sets
- Unauthorized extensions

XML Error Handling: Draconian

Microsoft and Netscape (together) proposed to XML commitee
An XML document is, by definition, "well-formed"
If there is a tagging or structure error, processor must quit
Result of this:
- All XML parsers must produce the same parse tree (output to processor) from the same XML document
- Consistent parsing means interoperability

Converting Documents from HTML to XML

(These are logical steps; actual steps may blend/merge)

Change HTML tags to XML tags
Make document follow XML rules
Enhance with more content tagging
Enhance with new links
Validate to a document model (optional)

Objectives of Conversion to XML

There are many objectives, but two are most important:

(Well-formed) XML is easier to process
- More consistent across vendors
- More choice in tools and methods
- Tools are more lightweight, APIs more standard....
XML tagging can be richer, more descriptive
- "Separate format from content"
- Support more data reuse
- Publish in other formats?

These two objectives may go together, but don't have to : decide what your needs are.

Relation between XML and HTML

XML is defined as a syntax
HTML is defined as a vocabulary
A given markup language might be either or both (or neither)

Many Levels of Conversion

Case 1: HTML to Well-formed XML
Case 2: HTML to Structured HTML-XML
Case 3: HTML to XHTML
Case 4: HTML to User-defined Structure with a DTD/Schema
Case 5: HTML to User-defined Content with a DTD/Schema

Case 1: HTML to Well-formed HTML

This is the simplest case
XML can be any tag set, so:
- Keep the HTML tags
- Create "well-formed" XML

Rules of Well-formed XML

Document is a tree with a single root
All elements must start and end
No elements overlap
There are rules for
- Names
- Attributes
- Markup characters inside content

All Elements that Start Must End

Every element has a start tag and an end tag <html></html>, <font></font>
No unmatched end tags
Exception: empty elements, which may be either:
- <img src="myfile.jpg"></img>
- <img src="myfile.jpg"/>

Since Document is a Tree, Elements May Not Overlap

Bad: <element>text<another>aaa</element>bbb</another>
Okay: <element>text</element> <another><element>aaa</element>text</another>

XML Naming Rules

Element names, attribute names, entity names, etc.

Can be as long as needed
May not contain spaces
Are CaSe SenSiTive: <author> ≠ <Author> ≠ <AUTHOR>
Start and end tag names must match exactly: <author>...</author>

XML Attribute Rules

Element name required
Attribute name required
Equals sign "=" required
Paired (single or double) quotes are required

               <element attribute="value">

Markup Delimiters Inside Data

Inside textual data and
Inside attribute values
- A less-than sign "<" must be "<"
- An ampersand "&" must be "&"

A Special "Gotcha": Empty Elements

Empty elements are elements with no content
Examples in HTML:
- <br> for line breaks
- <hr> for horizontal rules
- <img src="myfile.jpg"> for images
XML tagging must have both open/close, or"sole" tag, e.g.<br/>, <hr/>, <img src="myfile.jpg"/>
-- But Netscape 4.x doesn't recognize<br/> or <hr/> (IE does)

Solution: To "Trick" the Browser

Netscape does recognize <br /> (note extra space!)
Force this by using a "dummy" attribute, e.g.
- <br class="br"/>
- <br class="x"/>
These will display correctly, should not be munged by tools, and are well-formed XML

Consider Some Bad Code

See exhibit-1 (some HTML code) and exhibit-2 (a screenshot of how it appears in a browser).

An example:

</p>
<b><font face=sans-serif size=-1 color=#008B00>Habitat:</b>
</font>By river banks, in ditches and in wet spots.</p>

What Makes This So "Bad"?

Attribute values unquoted
Unbalanced tagging
- Start tags, no end tags (e.g. </p>)
- End tags, no start tags (e.g. <dl>)
- Unmatched tags (e.g. <H4>...</h4>)
- Overlapping elements
- No </html> close tag!
Gratuitous tagging
- Extra <font> tags, <i> tags...
Inconsistency
- Different tagging, same effect
- E.g. sometimes </p>, sometimes <br> <br>...

What We Do to Fix It

Supply missing quotes in tags (attribute values)
Fixed empty elements
- <hr> becomes <hr />, etc.
Supply missing tags (start or end)
Fix element overlapping

What Did We Achieve?

HTML file is now well-formed
Can be parsed, processed, in general-purpose XML software
- Displayed (with stylesheet)
- Processed (sorted, filtered etc.)
- Analyzed
- Enhanced
Can still use HTML software (since tags are still HTML)

A Trivial Document Conversion (Usually)

Few to no decisions to be made
No subject knowledge required
No XML or parsing knowledge required (just well-formedness rules)
Whole process can be automated
Any tool will do (XSL, Perl, Python, OmniMark)

What Conversion Will Mean

Add root <html> if not there
Solve name case matches by case-folding
Quote all attributes
Add end tags to keep structure flat
- Most structures end when next one starts <H1>, <p>...
- Only a few structures contain other structures (<html>, <body>, <table>...)
- Inline tagging (e.g. <i>) should already be balanced ... just make nesting clean

What are the Complicating Factors?

End tags may not match anything that ever started
Element overlap may need human intervention
There is no requirement that existing structure make sense
Sometimes difficult to determine where elements really end

What Hasn't Changed?

Document is still HTML
Any HTML browser can display it
All the old errors (except spare end tags) are still there
There is no improvement in
- Data reuse
- Retrieval precision
- Print (or other) formatting capabilities

Processing: The Good with the Bad

Good: no extra information is needed
Bad: no extra information is added
Good: data interchange improves
- Easier to determine start/end/completion
- Processing marginally easier
Bad: No enriched linking or content

What Do You Gain

Document may still be ugly, but data can be used with
- Most standard HTML tools (served as media type text/html)
- All standard XML tools (served as media type text/xml or media type application/xml with style sheet support)
- DOM (Document Object Model) applications for XML or HTML will work: consistent processing can be ensured
Clean markup is easier to maintain!
XML editors can make maintenance, cleanup even easier

Case 2: HTML to Structured HTML-XML

All XML documents are nested structures
More useful conversion would
- Keep HTML tags
- Add tags for structure
- Capture the nesting in your HTML document
- Create proper hierarchical structure

What Conversion Will Mean

Same as well-formed HTML-XML case, plus
Add tags intelligently to indicate structure, e.g.,
- <H1-div>
  - Starts with a <H1>
  - Ends just before the next <H1> in source
- Most elements contain other elements

Sorts of Questions that Need to be Asked

Rules need to be established, e.g.,
- Ordinary rules of logical structure
- Style or writing guidelines
- Formal document modeling rules (DTD or schema)
Rule examples:
- Can paragraphs nest, or does a new one end the previous?
- Is an <H2> allowed inside a <p>?
- Is this a strict hierarchy? (H1-sections contain H2-sections, which contain H3-sections, ad infinitum )
- Is this a loose hierarchy? (any kind of section in any order, they don't nest)
What tags for structure? All <div>? Or enforce hierarchy with levels?
Must tags conform to HTML standard? (browsers will forgive even if not)

Adding Structure To Our Example

See exhibit-4 (some HTML code) and exhibit-5 (a screenshot of how it appears in a browser).

Notice how:

Section on Organization appears "inside" main text
Sections on Primary Names , Habitat etc. appear "inside" Organization
But this organization is implicit -- levels of nesting are indicated (only) by heading level

A Moderate Conversion (Usually)

If documents are cleanly structured
- Rules are easy to devise
- Conversion is simple
Knowledge of structure now a serious requirement
Still no subject knowledge required
Still no XML or parsing knowledge required
Special care must be given for your result to be W3C-conformant HTML (our example isn't)

Automation and Tools

Process can be automated
- Automation is more complex
- Exception file may need to be built
- Results must be checked by both person and parser
Easier with tools that understand structure (XSLT, OmniMark, Balise, et al.)

What are the Complicating Factors?

Random end tags break hierarchy
Element overlap may still need human intervention
There is no requirement that existing structure make sense
If documents are a mess
- Automatic conversion breaks down
- Human judgement will be needed

Processing: Structured Data is More Useful

Structural information has been added
Because data now consists of discrete, hierarchically related chunks
- Data interchange improved
- Data reuse easier
Only minor improvements in retrieval precision
No enriched linking or content

Gains From Explicit Structure

All the gains from well-formed HTML-XML, plus hierarchy can be used:

To produce navigation aids, like automatic ToC
To increase searching precision, a little
For intelligent reuse in electronic cut and paste

Case 3: HTML to XHTML

XHTML is

First major change to HTML since 1997
A reformulation of HTML 4.0 in XML
Designed for internationalization, accessibility, and user-agent and alternate platform access
Modularized for easy reuse, use in other DTDs

XHTML provides

XML DTDs for HTML 4.0
- (Did you know that HTML 4.0 was defined with three SGML DTDs? Most people and applications used the tags from HTML 4.0 but ignored the DTDs. Most current HTML isn't SGML, but it could have been)
The ability to create HTML that is also Valid XML (using a public DTD)
The advantages of Case 2, plus expectation that others will know how to process your HTML.

XHTML specification available at:

A Caveat

XHTML means code is valid to a model (DTD)
This assures not only that code is well-formed, but also that tags, attributes are as described in formal definition of XHTML
This does not assure that code is "good"
- Structural information (cf. Case 2) may still be missing
- "Tag abuse" still an option

What Conversion Will Mean

Same as HTML to Well-formed HTML-XML, plus adjustment as needed to match XHTML definition
May require adding wrapper tags or re-tagging if illegal tags used
Remove embedded stylesheet and scripts
- preferably to an XSL stylesheet associated with the document
- or (CSS or Javascript) to external file
  - Can be left in place if well-formed
- Comments no longer a safe hiding place; XML processors may strip

Sorts of Questions that Need to be Asked

Which of the XHTML DTDs to use:
- XHTML-1.0-Transitional
- XHTML-1.0-Strict
- XHTML-1.0-Frameset
Make the XHTML "Strictly Conforming"?

What's the Difference (Between Kinds of XHTML)?

XHTML-1.0-Transitional
XHTML-1.0-Strict
XHTML-1.0-Frameset

Conforming to XHTML

Valid according to one of the XHTML DTDs
Root element
- is <html>
- designates XHTML namespace using xmlns attribute
DOCTYPE declaration
- before root element
- uses Formal Public Identifier provided by W3C
- May use local System Identifier

A Bit of Trivia

In XHTML, all tags are lower case

<h1> not <H1>
<img src="PrettyPic.jpg"/> not <IMG SRC="PrettyPic.jpg">

Example of XHTML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html 
   PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Sample XHTML Document</title>
</head>
<body>
<p>This is a small XHTML document.</p>
</body>
</html>

An Example of Transitional XHTML

exhibit-7: compare to exhibit-3
What are the differences?
- DOCTYPE declaration (line 1)
- Namespace declarations (in html start tag)
- All tags in lower case
- Required elements supplied (head element)
This is enough to be valid!

The Same Example, Only Strict

exhibit-8: compare toexhibit-7
What are the differences?
- Some (formatting) tags not allowed
  - font elements
  - attributes on body
Use CSS instead, e.g.
- <span style="...">...</span>
- style element (for body element formatting)
Warning: current (generation 4) browsers don't support CSS completely or consistently

Problem: Structure in XHTML

In exhibit-6, we used custom tagging to show structure
XHTML doesn't allow us to make up new tags
Solution: use XHTML generic div elements for structure: see exhibit-9

HTML Tidy: An Off-the-shelf Tool

From W3C (Dave Raggett)
Free!
Download from
Will clean up most basic problems
- By default, makes HTML 4.0 (not XML)
- Can make XHTML
See exhibit-10

Results of Running HTML Tidy

(See exhibit-10)

Missing head, title elements were supplied, but title has no content
Bad </p> construction replaced not with wrapping p elements, but with multiple <br />
Pretty good for a dumb machine!

A Moderate Conversion (Usually)

If documents are cleanly structured
- Rules are easy to devise
- Conversion is simple
XML and parsing knowledge required
- Tagged document must be valid according to an XHTML DTD
- Validation errors must be fixed; error messages from most tools confusing to beginners

Automation and Tools

Process can be automated
- Automation is still more complex
- Results must be checked by both person and parser: tools that make valid XML may add a lot of undesirable tagging to create a valid document; often should be cleaned up by hand
Easier with tools that understand structure (XSLT, OmniMark, Balise, et al.)

What are the Complicating Factors?

Selection of DTD
Addition of XML infrastructure to document
Validation and correction require understanding parser messages, XHTML DTD.

Gains from Valid XHTML

All the gains from Well-formed HTML-XML, plus

General purpose software increasingly available to manipulate XHTML
Data interchange improved
Data reuse easier

Can still use XHTML and reflect (some) structure (see exhibit-9)

Interlude: Some Real-World Problems

Tables for formatting
Navigation information in pages
Entities for special characters

HTML Tables (and Their Discontents)

The problem: HTML tables often used to control layout
Specific case of more general problem: mixing format with content
See exhibit-11, exhibit-12
- This example has a table nested three deep. In real life they can be much more complex.

Dealing With Tables Used for Layout

Two choices:

Mix presentational code (e.g. tables, font elements) with descriptive code, or
Separate problem into layers:
- Source document contains only clean descriptive code: "content"
- Presentation document created from source

Choice One: Mixing Descriptive and Presentational Code

Advantages:
- "Quick and easy" (as least until there's a lot of it)
Disadvantages:
- Hard to maintain
- Hard to validate; DTD (if any) is a mess!
- Pages get large, unwieldy, obtuse

See exhibit-14

Choice Two: Separating Content from Format

Advantages:
- Data no longer locked into one presentation/platform
- Content and presentation can be designed/maintained separately, so system is more scalable and long-lived
Disadvantages:
- Usually cannot use off-the-shelf tag set (since it must describe your content)
- Requires validation outside browser (via custom DTD or schema)
- Requires infrastructure (application) to convert from source (one format) to presentation (another format)
- Typically a stylesheet application

How do we do this? Stay tuned....

Navigation Apparatus in HTML

Problem: HTML pages typically contain more-or-less complex navigation information
- Button bars for web site navigation
- Internal links
Creation and maintenance is a chore (sometimes a headache!)
Another reason to separate content from format (treat navigation information as part of "format"):
- Much of it boilerplate (applied alike to all similar pages)
- Much of it computable (given simple parameters)

Entity Declarations for Special Characters

HTML authors are used to named entities for characters not in basic character set
- e.g.   (non-breaking space), ©(copyright sign), — (em dash), Á(capital A with acute accent, Á
These are built into browsers, but in XML must be declared
- XHTML DTD declares, so okay there
- If not XHTML, we must declare them ourselves (see exhibit-13 for an example)
- One more reason to use XHTML or design our own DTD

Note: Particular Problem With Internal Declarations

If we declare entities ourselves, we break our pages in generation 4 browsers!
- See exhibit-15
- Why? because the HTML parser in Netscape Navigator 4.x does not parse XML DOCTYPE declaration properly, treats closing ]> as data
- Also tested in IE5.5 (same problem)
Another reason to have an external DTD (no declarations in page code)

Case 4: HTML to User-defined Structure with a DTD/Schema

Structure is user-specific
Document Model explicitly defines document structure, e.g.:
- Transaction = Address-header followed by Supplier-header followed by Transaction-body
- Document = one or more Parts; Part = one or more Chapters; Chapter = one or more Sections
Document Type Definition (DTD) or schema used to define structure
Document can be validated against structure

"Valid" is a Step Beyond "Well-formed"

An XML document is valid if it:

Is well-formed
Has a document model (DTD or schema)
Matches that model

(The document is valid "according to the DTD/schema")

A DTD (Document Type Definition)

Models one type (class) of document (email message, memo, help-topic, journal article, bank transfer)
Is a set of rules describing how documents of that type can be marked up
Is written in the formal syntax of XML

DTDs Express Rules

for example:

article =metadata followed by article body , followed by optional back matter
paragraph = data characters including emphasis and/or hyperlinks and/or index terms
error message = error code number followed by message text
link has a "name" attribute and a "target" attribute

DTDs Model Document Types

DTDs:
- Name all the tags
- Model each element's content
- Name and define all attributes
- Name and define all entities (e.g. special characters)
DTDs do not:
- Provide real data typing
- Model multi-element or other complex dependencies

Why Are DTDs Useful?

To share information, share the DTD
- DTD ensures documents conform to model
- Parties don't have to share processors or applications
DTDs often used in sets. Different but related DTDs can:
- Provide conformance-testing at milestones in document lifecycle
- Be more or less permissive
DTDs can also automatically customize applications

Architecture of an XML Document

XML Declaration (names XML version and options)
Document Type Declaration (optional)
- Names the class of document (the root element)
- May contain declarations that are part of a DTD
- May point to an external DTD
The Document (tags and text)

DTDs versus Schema

DTD is current XML modeling syntax
Future modeling syntax will include at least one schema language
There have been several schema languages proposed (XML-Data, SOX, DCD, X-Schema. etc.)
W3C Working Group is working on one as this is written (may be done as we speak)

What the Schema Proposals Have In Common

XML syntax used for the modeling
- Conforming processor needs only one parser
- XML editor can create a schema
- Documentation can be integrated in a standard way
New modeling features
- Strong data typing
- Inheritance mechanisms
- Default values for elements
- New relationship types

How a DTD/Schema Helps Conversion

Lists all tag names
Names all valid nesting
Lists all attribute names
Conversion will consist of determining mapping

What Conversion will Mean

Root element determined by DTD/schema
Names must match DTD/schema (which can be used to create lookup table)
Document must still be well-formed
Conversion must go from HTML "dumb" structure to specific intelligent structure
Must determine each element mapping in advance, for example
- <H1> maps to <chapter><title>
- <H1>Introduction</H1> maps to <intro>

Sorts of Questions that Need to be Asked

What structures are significant for
- Display
- Searching
- Authoring
- Reuse
Should the model be strict (enforcing ) or loose (enabling )?

Descriptive versus Prescriptive

Prescriptive models are used to create new documents
- Strict rules for organization and sequence
- Many required elements
- Data typing specific (dollar-amount, date, time-sequence)
- Variability restricted
Descriptive models match existing (potentially diverse) documents
- Loose rules for organization and sequence
- Many optional elements
- Great variability allowed

Example: A Very High-level Structural XML

exhibit-16 shows a very high-level markup language used to create catalog listings (document and DTD are shown)
Some formatting information is specified as parameters, but not much
Document model is descriptive, but only of pages in a very abstract way
But enough information is here to create something like exhibit-3 (see code in exhibit-2) or even exhibit-13 (see code in exhibit-11)
This kind of markup is versatile and easy to create/maintain; but of limited usefulness.

A More Descriptive Structural XML

See exhibit-17
If HTML source is very clean, this code could be autogenerated
More descriptive elements support better
- search/retrieval/indexing
- formatting options on output

Medium to Difficult Document Conversion

Structural mapping decisions need to be made
Only moderate subject knowledge required, since DTD is for structure only
DTD knowledge required to determine structure
Parsing knowledge required for checking
Process can be partially automated
XML tool with knowledge of DTD useful but not essential

What are the Complicating Factors?

Since result is highly structured, good structure in source is essential
- Misplaced, missing or random end tags more likely to be fatal
- Structures that make no sense will not convert
- Badly structured source will need to be rewritten
- Granularity may not fit; there may be no good element-to-element match
- If/when no good structural match, you're in trouble:
  - Throw away information in the source?
  - Change the target language? (if possible)
  - Map on case-by-case basis? (manually)
Useful approach: clean up HTML first, then translate

Tool Issues

After conversion, you will not have HTML anymore.
XML-aware tools will make it easier to
- Convert
- Cleanup post conversion
- Author
- Maintain
- Produce new output (including fresh, clean HTML)

Repository Architecture Issues

In HTML, boundary of file = boundary of display ("page")
When you separate content from format, this is no longer necessary
- Files can be split for presentation, and/or
- Files can be aggregated for presentation
Becomes a workflow/data-management issue
"Minimal Revisable Unit" (MRU)

Gains During the Conversion Process

DTD provides much extra information
Autotagging programs that read DTDs can guide match choices
Normalizing programs can add end tags correctly, given start tags, making inferences from required structure
Default and required attributes can be added based on the DTD

What Can You Now Do with the Data

Search
- For a specific document structure (e.g., all index entries or methodology sections)
- Inside (or excluding) specific structures (e.g., scope, requirements, rejected-options, recommendations)
Reuse and repurpose data to build subsets and spin-offs (e.g., all the abstracts for an abstract journal)
Provide richer formatting for both print and electronic media
Drive new processes from the tags

-- All depending on richness of data

XML-aware Tools Make it Possible

To help authors build "correct" documents
To ensure that markup is consistent
To validate document structure (e.g., only valid documents made public)

Case 5: HTML to User-defined Content with a DTD/Schema

"Up-translation" to a richer tagset
Tags are content-based as well as or instead of structure-based
Granularity may be very different
DTD or schema provides content tags
Structure and content can be validated
Both content and structure tags are user-specific
- Error Message = Error_number followed by Error-type followed by Descriptive_text, followed by Resolution_description
- Document = Summary followed by Methodology followed by Discussion followed by Conclusion

A Fully-tagged Herbal

Tags describe structures and content
Presentation can be derived flexibly: see for output
Can also be indexed
- "Document" becomes structured data set
- See

Difficult Conversion

All the structural problems of the last case
Plus, great opportunity to add value to document (decisions must be made!)
Subject knowledge is required
Full XML and parsing knowledge required
Structure conversion can be automated, though not at 100%
Some content conversion may be automated

What Subject Conversion Adds to Previous Cases

Usually subject tagging may not be automated at all
Subject expert may be needed for
- Complete tagging
- Correct tagging
Subject experts are expensive (doctors, lawyers, electrical engineers)

Subject Tagging is an Implied Promise

If subject tagging is possible and
Some content is tagged with subject tags
Users will
- Assume all content is so tagged
- Build retrieval expectations on that “promise”

Content Tagging: An Opportunity

Tagging content increases value of the data
- Link elements to definitions, graphics, related websites
- Identify even small inline items as specific content (person-name, geographical-name, hardware-platform, genus, software-product)
- Control document content by subject
Drive subject-specific behaviour
- student materials and instructor guide from same source
- database updates or other transactions

Data Can Now Be Used to Provide

Precision searching for specific content
Highly structured finding and navigation aids
- E.g., indexes by drug names, part numbers, or subject keywords
Customized processing specific to the content (content-based applications)
- E.g., input forms, fancy validation, database loading or querying, driving devices
Multiple views of the same content that look very different
- E.g. "student copy" vs. "instructor copy"

Backfile Conversion

In both structure and content cases, DTD provides rules
So during document conversion:
- All well-formedness rules still apply
- Structure/content must match DTD

When the Document Does Not Match the DTD

There are (only!) three options

Change the DTD
- Public DTD
- Private DTD
Rearrange/rewrite the document
Leave this document out of the conversion effort

The W3C has Provided Tools

HTML Validation Service (validate against HTML 4.0)
HTML Tidy
- Standalone tool for checking, rationalizing HTML
  - "Fixes" many markup errors (but valid may not be correct)
  - Converts HTML to well-formed XML (but may be surprising)
  - Try running more than once over same file!
- Pretty-prints too

Many Other Tools Also Available

XSplit
HTML-Kit
MozquitoFactory
XMLMate
etc.

How Do I Translate from HTML to XML?

Not a complete question
Not a meaningful question
- For what purpose?
- For whom?
- Most critically: Into what tag set?

HTML to XML May Not Be Simple

Translation may be

One to one (<p> to <para>)
One to many (every <h1> to a different named tag such as <intro> and <summary>)
Many to one (every <strong> and <b> to <emph type="bold">)

Other Element Mapping Complications

Elements may

Turn into attribute values (<hr> to rowsep or frame attribute in tables) (<ul> to <list type="bullet">)
Need to appear where nothing was before
Disappear
- Wrong granularity
- Their function performed by style sheet
- Their function performed by an applet, script or stylesheet

XML Must be Hierarchical

Hierarchy in HTML may be
- Implied
- Absent
- Wrong (that is, illogical)
Determining where an element ends can be
- Easy
- Difficult
- Impossible (document must be rewritten)

Subject Tagging Complications

Granularity differences
- No tags mark the item; human or AI must identify
- One item goes to multiple, based on content (<blockquote>to<poem>or<code_fragment>or<man-machine-dialog>
Subject knowledge -- Need for subject-experts to identity content

Is Round Trip Possible? XML to HTML

Trivial conversion
100% programmatic conversion (XSLT, Perl, OmniMark, Python, etc.)
But
- Original source will not be returned
- "Stray" markup is lost
- New HTML will be "clean" (and maybe well-formed XML)
- New HTML might be hierarchical

Exhibit 1: Some Bad HTML

file: comfrey.bad.html

<html>
<body link=#8B0000 vlink=#8B0000 bgcolor=#FFFFFF>
<!-- coded by hand, with content from herbal.simple.html -->
<H1><FONT color=#008B00>Comfrey</h1></font>
<h4><i>Symphytum officinale</h4></i>
</p>
<b><font face=sans-serif size=-1 color=#008B00>
Habitat:</b></font> By river banks, in ditches and in wet spots. 
</p>
<b><font face=sans-serif size=-1 color=#008B00></font>
<font face=sans-serif size=-1 color=#008B00>Also called:</font>
</b> Knitbone; Knitback; Consound; Blackwort; Bruisewort; Slippery 
Root; Boneset; Consolida; Ass Ear <br>&nbsp;
<br>
<b><font face=sans-serif size=-1 color=#008B00>Treatment for: 
<i></font></b><b><font color=#008B00>wounds; 
broken bones; ulcer; hernia; haemorrhage; bronchitis</font></b>
</H4></I>
<DL>
<DT>
<b><font face=sans-serif size=-1 color=#008B00>Preparation:
</b></font>
<br>[Root, rhizome, leaf]
<DD>Unearth the roots in spring or autumn. Split and dry in fairly 
cool place. Infuse one to three tsp of the dried herb in a cup of water, 
bring to a boil and let simmer for 10-15 minutes.
</dl>
</p>
<b><font face=sans-serif size=-1 color=#008B00>Active 
ingredient:</b></font> Allantoin 
<h4>vulnerary;  demulcent; anti-inflammatory; astringent; 
expectorant</H4>
<font size=-1>A relative of the forget-me-not, comfrey is 
recognizable by its broad, hairy leaves. One of the best known of 
traditional herbal treatments; its use goes back at least to the Middle 
Ages and into the indefinite past. Has been used for gout and aching 
joints as well as for all kinds of breaks, wounds and ulcers.</FONT>
</body>

Exhibit 2: Screen Shot of Some Bad HTML

file: comfrey.bad.jpg

See exhibit-1 for the code: this stuff displays just fine (in Netscape 4.x). This shows how forgiving the browser is. (Or how forgiving this browser is.)

Exhibit 3: The Same Page Cleaned Up

file: comfrey.wf.html

<html>
<body link="#8B0000" vlink="#8B0000" bgcolor="#FFFFFF">
<!-- hand-corrected well-formed version of comfrey.bad.html -->
<h1><font color="#008B00">Comfrey</font></h1>
<h4><i>Symphytum officinale</i></h4>
<p>
<b><font face="sans-serif" size="-1" color="#008B00">
Habitat:</font></b> By river banks, in ditches and in wet spots.</p>
<p>
<b><font face="sans-serif" size="-1" color="#008B00">
Also called:</font></b> Knitbone; Knitback; Consound; 
Blackwort; Bruisewort; Slippery Root; Boneset; Consolida; Ass Ear</p>
<p>
<b><font face="sans-serif" size="-1" color="#008B00">Treatment for: </font></b><b><font color="#008B00">wounds; broken bones; ulcer; hernia; haemorrhage; bronchitis</font></b></p>
<dl>
<dt>
<b><font face="sans-serif" size="-1" color="#008B00">Preparation:</font></b>
<br class="br"/>[Root, rhizome, leaf]</dt>
<dd>Unearth the roots in spring or autumn. Split and dry in fairly cool place. Infuse one to three tsp of the dried herb in a cup of water, bring to a boil and let simmer for 10-15 minutes.</dd>
</dl>
<p>
<b><font face="sans-serif" size="-1" color="#008B00">
Active ingredient:</font></b> Allantoin</p>
<h4>vulnerary;  demulcent; anti-inflammatory; astringent; 
expectorant</h4>
<p><font size="-1">A relative of the forget-me-not, comfrey is 
recognizable by its broad, hairy leaves. One of the best known of 
traditional herbal treatments; its use goes back at least to the Middle 
Ages and into the indefinite past. Has been used for gout and aching joints 
as well as for all kinds of breaks, wounds and ulcers.</font>
</p>
</body>
</html>

Exhibit 4: HTML With Implicit Structure

file: intro.html

<html>
<!-- well-formed version with content from herbal.simple.html -->
<body link="#8B0000" vlink="#8B0000" bgcolor="#FFFFFF">
<h1><a name="intro">A Garland of Herbs</a></h1>
<p>This miniature herbal is created as a demonstration of structured 
data published in non-proprietary formats (HTML and XML). It is 
<i>not</i> intended for use as a reference on herbal remedies. 
Compiled by a non-expert from publicly-available sources, its content is 
not deliberately falsified or distorted; nevertheless it should not be 
regarded as authoritative in any way.</p>
<p>While the contents of the herbal may not be trustworthy, however, 
its <i>structure</i> should be perfectly serviceable for the 
need: to present organized information in a way that both improves access 
for readers, and renders the dataset suitable for such automated processes 
as  indexing and filtering.</p>
<h2><i><font face="sans-serif">
<a name="Organization">Organization</a></font></i>
</h2>
<p>There is a consistent organization to each entry. Note that not 
all entries have all sections.</p>
<h3><font face="sans-serif"><a name="Primary.Names">
Primary Names</a></font></h3>
<p>Each herb is listed with its common name and its formal (Latin) 
botanical name.</p>
<h3><font face="sans-serif"><a name="Habitat">
Habitat</a></font></h3>
<p>Where the herb is commonly found is listed as its habitat. This 
section is mainly for interest: amateurs are not encouraged to go to 
anyplace described, harvest a likely candidate, and boil it up.</p>
<h3><font face="sans-serif"><a name="Also.called">Also 
called</a></font></h3>
<p>Any names by which the herb or plant may also be commonly known 
are listed here.</p>
<h3><font face="sans-serif"><a name="Treatment.for">
Treatment for</a></font></h3>
<p>Common ailments for which the herb is a known palliative (or even 
a cure), are listed here. This list is not exhaustive, of course; nor is 
it necessarily correct. (Herbal medicine has largely been an inexact 
science.)</p>
<h3><font face="sans-serif"><a name="Preparation">
Preparation</a></font></h3>
<p>Any preparation(s) for the herb is (are) described in this 
section. If different parts of the plant are used, their preparations are 
described separately.</p>
<h3><font face="sans-serif"><a name="Active.Ingredients">
Active Ingredients</a></font></h3>
<p>In some cases, where the active chemical component or components 
of an herb are known, they are listed here.</p>
<h3><font face="sans-serif"><a name="Effects">Effects
</a></font></h3>
<p>Medical terms describing the pharmacological effects of the herb 
(e.g. <b>sedative</b>) are listed here.</p>
<h3><font face="sans-serif"><a name="Description">
Description</a></font></h3>
<p>Each herb is briefly described in one or more paragraphs.</p>
<h3><font face="sans-serif"><a name="Notes">Notes
</a></font></h3>
<p>Any supplemental notes on the herb, especially respecting possible 
warnings associated with it, appear here.</p>
<h2><i><font face="sans-serif"><a name="Sources">
Sources</a></font></i></h2>
<p>This guide is adapted from several sources on the Internet (see 
references below). </p>
<h2><i><font face="sans-serif"><a name="references">
References</a></font></i></h2>
<p><font size="-1">Botanical.com, a hypertext edition of A 
Modern Herbal (M. Grieve, 1931) 
<a href="http://www.botanical.com/botanical/mgmh/mgmh.html">
http://www.botanical.com/botanical/mgmh/mgmh.html</a></font>
</p>
<p><font size="-1">Herbal Medicine Center at Healthworld 
Online: see <a href="http://www.healthy.net/clinic/therapy/herbal/">
http://www.healthy.net/clinic/therapy/herbal/</a></font>
</p>
<p><font size="-1">The Warnings page of Dr. Yang's Herbs and 
Gems for Health: <a href="http://www.ocnsignal.com/yangwarn2.shtml">
http://www.ocnsignal.com/yangwarn2.shtml</a></font></p>
<hr />
</body>
</html>

Exhibit 5: Screen Shot of HTML With Implicit Structure

file: intro.jpg

Exhibit 6: New Tags Make Structure Explicit

file: intro.struct.html

<html>
<!-- well-formed version with content from herbal.simple.html
     enhanced with non-HTML tagging -->
<body link="#8B0000" vlink="#8B0000" bgcolor="#FFFFFF">
<H1-DIV>
<h1><a name="intro">A Garland of Herbs</a></h1>
<p>This miniature herbal is created as a demonstration of structured 
data published in non-proprietary formats (HTML and XML). It is <i>not</i> intended for use as a reference on herbal remedies. Compiled by a non-expert from publicly-available sources, its content is not deliberately falsified or distorted; nevertheless it should not be regarded as authoritative in any way.</p>
<p>While the contents of the herbal may not be trustworthy, however, 
its <i>structure</i> should be perfectly serviceable for the 
need: to present organized information in a way that both improves access 
for readers, and renders the dataset suitable for such automated processes 
as  indexing and filtering.</p>
<H2-DIV>
<h2><i><font face="sans-serif">
<a name="Organization">Organization</a></font></i>
</h2>
<p>There is a consistent organization to each entry. Note that not 
all entries have all sections.</p>
<H3-DIV>
<h3><font face="sans-serif"><a name="Primary.Names">
Primary Names</a></font></h3>
<p>Each herb is listed with its common name and its formal (Latin) 
botanical name.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Habitat">
Habitat</a></font></h3>
<p>Where the herb is commonly found is listed as its habitat. This 
section is mainly for interest: amateurs are not encouraged to go to 
anyplace described, harvest a likely candidate, and boil it up.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Also.called">Also 
called</a></font></h3>
<p>Any names by which the herb or plant may also be commonly known 
are listed here.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Treatment.for">
Treatment for</a></font></h3>
<p>Common ailments for which the herb is a known palliative (or even 
a cure), are listed here. This list is not exhaustive, of course; nor is it 
necessarily correct. (Herbal medicine has largely been an inexact science.)
</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Preparation">
Preparation</a></font></h3>
<p>Any preparation(s) for the herb is (are) described in this section. 
If different parts of the plant are used, their preparations are described 
separately.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Active.Ingredients">
Active Ingredients</a></font></h3>
<p>In some cases, where the active chemical component or components 
of an herb are known, they are listed here.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Effects">Effects
</a></font></h3>
<p>Medical terms describing the pharmacological effects of the herb 
(e.g. <b>sedative</b>) are listed here.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Description">
Description</a></font></h3>
<p>Each herb is briefly described in one or more paragraphs.</p>
</H3-DIV>
<H3-DIV>
<h3><font face="sans-serif"><a name="Notes">Notes</a>
</font></h3>
<p>Any supplemental notes on the herb, especially respecting possible 
warnings associated with it, appear here.</p>
</H3-DIV>
</H2-DIV>
<H2-DIV>
<h2><i><font face="sans-serif"><a name="Sources">
Sources</a></font></i></h2>
<p>This guide is adapted from several sources on the Internet (see 
references below). </p>
</H2-DIV>
<H2-DIV>
<h2><i><font face="sans-serif"><a name="references">
References</a></font></i></h2>
<p><font size="-1">Botanical.com, a hypertext edition of A 
Modern Herbal (M. Grieve, 1931) 
<a href="http://www.botanical.com/botanical/mgmh/mgmh.html">
http://www.botanical.com/botanical/mgmh/mgmh.html</a>
</font></p>
<p><font size="-1">Herbal Medicine Center at Healthworld 
Online: see <a href="http://www.healthy.net/clinic/therapy/herbal/">
http://www.healthy.net/clinic/therapy/herbal/</a></font>
</p>
<p><font size="-1">The Warnings page of Dr. Yang's Herbs and 
Gems for Health: <a href="http://www.ocnsignal.com/yangwarn2.shtml">
http://www.ocnsignal.com/yangwarn2.shtml</a></font></p>
</H2-DIV>
</H1-DIV><hr />
</body>
</html>

Exhibit 7: Transitional XHTML

file: comfrey.trans.xhtml

Compare to exhibit-3

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "lib/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- hand-corrected XHTML-valid version of comfrey.wf.html -->
<head>
<title>Comfrey</title>
</head>
<body link="#8B0000" vlink="#8B0000" bgcolor="#FFFFFF">
<h1><font color="#008B00">Comfrey</font></h1>
<h4><i>Symphytum officinale</i></h4>
<p><b><font face="sans-serif" size="-1" color="#008B00">
Habitat:</font></b> By river banks, in ditches and in wet spots.
</p>
<p><b><font face="sans-serif" size="-1" color="#008B00">
Also called:</font></b> Knitbone; Knitback; Consound; 
Blackwort; Bruisewort; Slippery Root; Boneset; Consolida; Ass Ear</p>
<p><b><font face="sans-serif" size="-1" color="#008B00">
Treatment for: </font></b><b><font color="#008B00">
wounds; broken bones; ulcer; hernia; haemorrhage; bronchitis</font>
</b></p>
<dl>
<dt><b><font face="sans-serif" size="-1" color="#008B00">
Preparation:</font></b>
<br class="br"/>[Root, rhizome, leaf]</dt>
<dd>Unearth the roots in spring or autumn. Split and dry in fairly 
cool place. Infuse one to three tsp of the dried herb in a cup of water, 
bring to a boil and let simmer for 10-15 minutes.</dd></dl>
<p><b><font face="sans-serif" size="-1" color="#008B00">
Active ingredient:</font></b> Allantoin</p>
<h4>vulnerary;  demulcent; anti-inflammatory; astringent; expectorant
</h4>
<p><font size="-1">A relative of the forget-me-not, comfrey is 
recognizable by its broad, hairy leaves. One of the best known of 
traditional herbal treatments; its use goes back at least to the Middle 
Ages and into the indefinite past. Has been used for gout and aching joints 
as well as for all kinds of breaks, wounds and ulcers.</font></p>
</body>
</html>

Exhibit 8: Strict XHTML

file: comfrey.strict.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "lib/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- hand-corrected XHTML-valid version of comfrey.wf.html -->
<head>
<title>Comfrey</title>
<style type="text/css">
body    { background-color: #FFFFFF }
a:link  { color: #8B0000 }
a:vlink { color: #8B0000 }
</style>
</head>
<body>
<h1 style="color: #008B00">Comfrey</h1>
<h4><i>Symphytum officinale</i></h4>
<p><b>
<span style="font-face: sans-serif; font-size: -1; color: #008B00">
Habitat:</span></b> By river banks, in ditches and in wet spots.
</p>
<p><b>
<span style="font-face: sans-serif; font-size: -1; color: #008B00">
Also called:</span></b> Knitbone; Knitback; Consound; Blackwort; 
Bruisewort; Slippery Root; Boneset; Consolida; Ass Ear</p>
<p><b>
<span style="font-face: sans-serif; font-size: -1; color: #008B00">
Treatment for: </span></b><b>
<span style="color: #008B00">wounds; broken bones; ulcer; hernia; 
haemorrhage; bronchitis</span></b></p>
<dl>
<dt>
<b>
<span style="font-face: sans-serif; font-size: -1; color: #008B00">
Preparation:</span></b>
<br class="br"/>[Root, rhizome, leaf]</dt>
<dd>Unearth the roots in spring or autumn. Split and dry in fairly 
cool place. Infuse one to three tsp of the dried herb in a cup of water, 
bring to a boil and let simmer for 10-15 minutes.</dd></dl>
<p><b>
<span style="font-face: sans-serif; font-size: -1; color: #008B00">
Active ingredient:</span></b> Allantoin</p>
<h4>vulnerary; demulcent; anti-inflammatory; astringent; expectorant
</h4>
<p><span style="font-size: -1">A relative of the forget-me-not, 
comfrey is recognizable by its broad, hairy leaves. One of the best known 
of traditional herbal treatments; its use goes back at least to the Middle 
Ages and into the indefinite past. Has been used for gout and aching joints 
as well as for all kinds of breaks, wounds and ulcers.</span></p>
</body>
</html>

Exhibit 9: Structured XHTML

file: intro.struct.xhtml

Compare to exhibit-6. Here, we have div elements with class attributes (valid in XHTML).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "lib/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!-- XHTML-valid version of intro.struct.html:
     structural tagging changed to be XHTML-compliant -->
<head>
<title>A Garland of Herbs</title>
</head>
<body link="#8B0000" vlink="#8B0000" bgcolor="#FFFFFF">
<div class="h1">
<h1><a name="intro">A Garland of Herbs</a></h1>
<p>This miniature herbal is created as a demonstration of structured 
data published in non-proprietary formats (HTML and XML). It is 
<i>not</i> intended for use as a reference on herbal remedies. 
Compiled by a non-expert from publicly-available sources, its content is 
not deliberately falsified or distorted; nevertheless it should not be 
regarded as authoritative in any way.</p>
<p>While the contents of the herbal should not be regarded as 
trustworthy, however, its <i>structure</i> should be perfectly 
serviceable for the need: to present organized information in a way that 
both improves access for readers, and renders the dataset suitable for such 
automated processes as  indexing and filtering.</p>
<div class="h2">
<h2><i><font face="sans-serif">
<a name="Organization">Organization</a></font></i>
</h2>
<p>There is a consistent organization to each entry. Note that not 
all entries have all sections.</p>
<div class="h3">
<h3><font face="sans-serif"><a name="Primary.Names">
Primary Names</a></font></h3>
<p>Each herb is listed with its common name and its formal (Latin) 
botanical name.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Habitat">
Habitat</a></font></h3>
<p>Where the herb is commonly found is listed as its habitat. This 
section is mainly for interest: amateurs are not encouraged to go to 
anyplace described, harvest a likely candidate, and boil it up.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Also.called">Also 
called</a></font></h3>
<p>Any names by which the herb or plant may also be commonly known 
are listed here.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Treatment.for">
Treatment for</a></font></h3>
<p>Common ailments for which the herb is a known palliative (or even 
a cure), are listed here. This list is not exhaustive, of course; nor is it 
necessarily correct. (Herbal medicine has largely been an inexact science.)
</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Preparation">
Preparation</a></font></h3>
<p>Any preparation(s) for the herb is (are) described in this section. 
If different parts of the plant are used, their preparations are described 
separately.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Active.Ingredients">
Active Ingredients</a></font></h3>
<p>In some cases, where the active chemical component or components 
of an herb are known, they are listed here.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Effects">
Effects</a></font></h3>
<p>Medical terms describing the pharmacological effects of the herb 
(e.g. <b>sedative</b>) are listed here.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Description">
Description</a></font></h3>
<p>Each herb is briefly described in one or more paragraphs.</p>
</div>
<div class="h3">
<h3><font face="sans-serif"><a name="Notes">
Notes</a></font></h3>
<p>Any supplemental notes on the herb, especially respecting possible 
warnings associated with it, appear here.</p>
</div>
</div>
<div class="h2">
<h2><i><font face="sans-serif"><a name="Sources">
Sources</a></font></i></h2>
<p>This guide is adapted from several sources on the Internet (see 
references below). </p>
</div>
<div class="h2">
<h2><i><font face="sans-serif"><a name="references">
References</a></font></i></h2>
<p><font size="-1">Botanical.com, a hypertext edition of A 
Modern Herbal (M. Grieve, 1931)

Converting HTML to XML

Biography

Organization

What is HTML?

What do HTML Tags Say They Do?

HTML Tags Really Do Nothing

What is XML?

XML Documents

XML Markup Identifies Document Components

Content Markup

Structure Markup

"Location or Navigation" Information

Metadata (Data about the Data)

Rendering/Processing Markup

HTML is (Implicitly) Formatting Markup

XML Tags Really Do Nothing

Differences Between XML and HTML

XML has no Pre-defined Tags

HTML Markup is "Loose"

XML Markup is Strict

HTML Structure is Flat

XML Makes Nested Structures

Structured Documents Contain Nested, Retrievable Objects

Advantages of Structured Documents

An XML Document is a Tree

Tree Structure Indicates Nesting

HTML Error Handling: Permissive

XML Error Handling: Draconian

Converting Documents from HTML to XML

Objectives of Conversion to XML

Relation between XML and HTML

Many Levels of Conversion

Case 1: HTML to Well-formed HTML

Rules of Well-formed XML

All Elements that Start Must End

Since Document is a Tree, Elements May Not Overlap

XML Naming Rules

XML Attribute Rules

Markup Delimiters Inside Data

A Special "Gotcha": Empty Elements

Solution: To "Trick" the Browser

Consider Some Bad Code

What Makes This So "Bad"?

What We Do to Fix It

What Did We Achieve?

A Trivial Document Conversion (Usually)

What Conversion Will Mean

What are the Complicating Factors?

What Hasn't Changed?

Processing: The Good with the Bad

What Do You Gain

Case 2: HTML to Structured HTML-XML

What Conversion Will Mean

Sorts of Questions that Need to be Asked

Adding Structure To Our Example

A Moderate Conversion (Usually)

Automation and Tools

What are the Complicating Factors?

Processing: Structured Data is More Useful

Gains From Explicit Structure

Case 3: HTML to XHTML

XHTML provides

A Caveat

What Conversion Will Mean

Sorts of Questions that Need to be Asked

What's the Difference (Between Kinds of XHTML)?

Conforming to XHTML

A Bit of Trivia

Example of XHTML

An Example of Transitional XHTML

The Same Example, Only Strict

Problem: Structure in XHTML

HTML Tidy: An Off-the-shelf Tool

Results of Running HTML Tidy

A Moderate Conversion (Usually)

Automation and Tools

What are the Complicating Factors?

Gains from Valid XHTML

Interlude: Some Real-World Problems

HTML Tables (and Their Discontents)