Authoring XML documents for viewing

It takes 2 files to produce a result on the screen, an XML file and an XSL file. The data is contained in the XML file while the style sheet (XSL) defines how this data is to be viewed.

If you just want to display <name> and <age> you need an xsl file, and a reference to this xsl file.

Example

Test.xml  Try it yourself see: http://216.147.84.84/download.html

Without an attached stylesheet (CSS, XSL), each application is using its own default mechanism for display.

The following source code will not show "My name" and "Age" in the browser window(IE 5)..
> <?xml version="1.0" standalone="yes"?>
> <page>
> <title>My first XML page</title>
> <para>This is cool</para>
> <list>
> <name>My Name </name>
> <age>Age</age>
> </list>
> </page>
See the trivial demo at http://www.ucc.ie/test.xml

For one possibility, try this ... insert the following line between the XML declaration and your <page> root element:

<?xml-stylesheet href="test.css" type="text/css"?>

Now, create a file called "text.css" with the following contents (and in the same folder as your XML doc):

page { font-family: georgia, serif; }
title {
display: block;
font-size: 2em;
color: maroon; background: silver;
border: medium groove white;
text-align: center;
margin: 0em 30%;
}

para {
display: block;
font: 1em verdana, sans-serif;
margin: 1em 0em;
}

list { display: block; color: navy; font-size: .9em; }

name, age { display: block; margin-left: 1em; }

*Now* display your XML doc in IE ...
========= 

One question
Is there a way to display a element in a XML document, and then display the value of the element, consider the following example:

<parameter>
<par1>12</par1>
<par2>21</par2>
<par3>22</par3>
</parameter>

I want to display:
par1: 12
par2: 21
par3: 22

Is this possible in with XSL and in that way how or do I have to rewrite my XML document to another form?? I would like you to check out these books.

Using the elements <par1>, <par2>, etc.:

<xsl:template match="/parameter/par1">
<fo:block>
<xsl:text> par1: </xsl:text>
<xsl:apply-templates/>
</fo:block>
</xsl:template>

<xsl:template match="/parameter/par2">
<fo:block>
<xsl:text> par2: </xsl:text>
<xsl:apply-templates/>
</fo:block>
</xsl:template>

<xsl:template match="/parameter/par3">
<fo:block>
<xsl:text> par3: </xsl:text>
<xsl:apply-templates/>
</fo:block>
</xsl:template>


Another solution (more generic) would be to use the parameter number as an
attribute. For example:

<paramList>
<param number="1">12</param>
<param number="2">21</param>
<param number="3">22</param>
</paramList>


Then the XSL might look like:

<xsl:template match="/paramList/param">
<fo:block>
<xsl:text>par</xsl:text>
<xsl:value-of select="@number"/>
<xsl:text>: </xsl:text>
<xsl:apply-templates/>
</fo:block>
</xsl:template>

At 18:59 7/08/1999 , Nicholas Ellingham wrote:

I would like to use it to handle some large documents that I wish to put on the web. By large documents I mean whole books and projects. What I am having trouble with is understanding what XML can do that HTML can't for large document handling. I know that XML allows you to define your own elements for example so large documents could easily be searched for specific text. But after that it seems a bit of a jungle understanding the extra benefits! I have bought books on XML, but their generic approach hasn't allowed me to gain specific knowledge geared to what I want to achieve. So what I'm basically asking is what can XML do for large document manipulation that HTML can't?

Well, this is how I see XML as being useful: - You store the source data in XML. This gives you a very rich storage format. This can then be passed into a number of powerful conversion systems such as Omnimark and Perl. The end result is a large number of HTML documents, all consistently formatted and cross-linked, and broken up into bite-sized
pieces.

This gives you the best of both worlds: - storage in a platform-independent format (XML), and publishing to a universally reabable format (HTML).- James Robertson, Step Two Designs Pty Ltd, SGML, XML & HTML Consultancy
http://www.steptwo.com.au/ jamesr@steptwo.com.au

Also would XSL be of any use to me in defining the look of the documents, does it have any edge over CSS as the moment?

CSS is really only usable with XML if the presentation and structure have the same ordering which is rarely the case with large documents that you are trying to present in different contexts.

CSS is also extremely usable if you're generating your documents on the fly from other sources of information, in which case it's easy to set up the 'ordering' during construction (servlets, ASP, JSP, CGI, etc.) without any need for XSL's transformative capabilities.

The large documents I tend to work with tend to be 'complete' documents - documents for which their internal structure maps to their presentation quite smoothly already.

Basically, it depends on what you need. Take a close look at your document structures and your presentation needs. If the presentation can be directly mapped to the existing document structure, stick to CSS. If you need to modify your document structure to display it properly, check out XSL. And remember, you can always do both. In the small number of cases where I have indeed found XSL useful, CSS provides a default presentation and XSL provides an alternate.
Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com
==================

[Linda van den Brink]
>You could have a master document in which the smaller components are
>included with file entities. This is a way to have one DTD but manage
>document components. For example:
>
><!DOCTYPE book SYSTEM "book.dtd" [
><!ENTITY firstchapter SYSTEM "chapters\chapter1.xml">
><!ENTITY secondchapter SYSTEM "chapters\chapter2.xml">
>]>
>
><book>
>&firstchapter;
>&secondchapter;
></book>
>
>The chapter files would not have a doctype declaration or <book> tags.
>
This works fine but does lead to large "bookish" DTDs. Many
element types will be required to handle book, part, chapter,
section, sub-section, sub-section1, sub-subsection1Variation1...
These DTDs have shown themselves to be problematic to create
and maintain.

A second effect is that that the book is parsed and processed
as a single unit. For high volume work, this can be a problem.

An alternative is the micro-document approach. This approach
leads to much smaller DTDs and has some significant engineering
advantages.

An example will illustrate:

<!DOCTYPE book SYSTEM "book.dtd">
<book>
<part><title>Part 1 -- Introduction</title>
<file>chapter1.xml</file>
<file>chapter2.xml</file>
</part>
<part><title>Part 2 -- Getting Started</title>
<file>chapter12.xml</file>
</part>
</book>

-----------
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<title>Chapter 1</title>
<p>
This is chapter 1
</p>
</chapter>
-------------------

In this approach the "book" is a stand-alone XML file that references other
stand-alone XML files[0]. The book parses to the book DTD. The chapters parse
to the chapter DTD. To down-translate the entire book, parse and load the book
instance and then, one-by-one, parse and load each chapter. The book instance
can give you all the context you need to create interlinked hypertext,
TOCs etc. Total memory hit = 1 chapter.

I find this approach scales much better than "bookish"[1] DTDs. It also
is intellectually pleasing as it treats documents as self-similar structures.
Fractals if you like. I.e. the structure evident at the book level is very
similar to the structure evident at the chapter level, is very similar to the
structure evident at the section level etc.

The above structure lends itself to what is in effect, a nested XML
parse[2]. We can choose to parse at the book level or drill down and
parse at the chapter level.

It is also a sensible structure for publishing as publishing applications
exhibit "local order"[3] when it comes to formatting semantics. That is
to say, the paragraph formatting that goes on in chapter 2 is not dependent
in any way to the paragraph formatting that goes on in chapter 1. So, why
process the book as a whole? It also scales nicely to volume sets, corpus,
libraries etc.
(I have a 3.5 GB collection of volumes that is modelled as a three level
deep micro-document architecture.

-------------
[0] Of course these should use XLink
[1] Term used by John McFadden (Omnimark) to differntiate monolithic
DTD architectures from micro-document architectures
[2] The SUBDOC feature of full SGML provides nested parsing (sort of)
[3] "DTDs should model local order" -- a profound observation by
John McFadden -- in my opinion.


<Sean URI="http://www.digitome.com/sean.html">
Developers Day Co-Chair, 9th International World Wide Web Conference
16-19, May, 2000, Amsterdam, The Netherlands http://www9.org
</Sean>

Use XSL to create content pages from my XML documents,
The "Modes" section of chapter 14 (http://metalab.unc.edu/xml/books/bible/updates/14.html) of Elliotte Rusty Harold's updated "XML Bible" shows an example.

================
> I'm hoping James Tauber will expound on this a bit...

Certainly.

> > CSS is really only usable with XML if the presentation and structure have the same ordering which is rarely the case with large documents that you are trying to present in different contexts. What I'm looking for is more insight into what it means to "have the same ordering".

What I mean is that CSS can't change the order of content in your document, or duplicate content. Imagine that your document has the structure:

<document>
<title>
<chapter>
<title>...</title>
...
</chapter>
<chapter>
<title>...</title>
...
</chapter>
<chapter>
<title>...</title>
...
</chapter>
</document>

CSS would have no problem displaying the contents of the entire document, making chapter titles a larger font, etc. But imagine you wanted a table of contents. A table of contents involves extracting the titles of the chapters and placing them before the actual chapters themselves. CSS can't do this because it involves duplicating and reordering certain content. XSL is specifically designed for this kind of thing. This is a document example. Consider a more data-like example:

<people>
<person>
<surname>...</surname>
<given.name>...</given.name>
</person>
<person>
<surname>...</surname>
<given.name>...</given.name>
</person>
<person>
<surname>...</surname>
<given.name>...</given.name>
</person>
</people>

CSS would have no problem displaying this list of people *in the order they appear in the XML*. But say you wanted to list the people sorted by surname. Again, impossible with just CSS. Easy with XSL.

I agree with Simon. If you don't need to do transformation, stick with CSS. It's come a long way and is quite good at styling an existing structure. But if you need transformation, XSL is worth looking at. Especially if your transformations are typical document transformations.

> Does the statement about "having the same ordering" suggest that there is only one method to declare the style and that for every declaration of style within the flow of text in its ASCII format must line for line be equivalent to that of the ASCII text that represents the text in the XML file?

Pretty much. With CSS2 you can add extra text and omit (by making invisible) other text, but you can't move one bit of text to a different place in the document.

> I'd be satisified using CSS as a transition period until I get myself through the challenge of learning XSLT and I'd like to at least know how to do so with as little waste as possible.

Don't think of CSS as just a transition. Even once you get into XSLT, at least if you are transforming to HTML, CSS will remain part of the solution. Hope this helps. James

This document describes the XML-RPC interface implemented by UserLand discussion groups. http://www.xmlrpc.com/discuss/msgReader$181