What is XSL?

What is XSL? - By: Jamie Simpson

XSL is a language for describing the style of a document, much like CSS (Cascading Style Sheets); however XSL is used to style XML (eXtensible Mark-up Language) documents. The syntax differs from CSS, yet can achieve the same results. In addition to this, XSL can be used as a transformation language (XSLT), and it can also use advanced styling, through using formatting objects, and building further on CSS.

XSL is only the visual half of the page you want to see. Behind the styling there is an XML document containing the content that you wish to show. The XSL will not contain any data, just as the XML will not contain any visual instructions.

An example of an XML document is laid out below:

< day>

< AM>< Breakfast>Cereals< /Breakfast>

< snack>Chocolate< /snack>< / AM>

< PM< lunch>Sandwich< /lunch>< snack>Crisps< /snack>

< dinner>Roast< /dinner>< / PM>

< / day>

The document has a logical meaning from looking at the English words which create the structure. This data could represent something like a typical day's food consumption.

This raw data could now be viewed on any Java enabled device, from a handheld to a supercomputer. Viewing it in this state would render an output similar to the raw data above. XSL would style this, creating a visually pleasing structure, with different fonts, colours, background images, etc. It could even display the data in a form other than a tree, perhaps grouping the AM and PM items together in boxes.

< xsl:template match="AM">

< fo:block font-weight="bold">

< xsl:apply-templates/>

< /fo:block>

< /xsl:template>

< xsl:template match="PM">

< fo:block font-style="italic">

< xsl:apply-templates/>< /fo:block>

< /xsl:template>

This would make all AM elements appear in a bold type face, and all PM in italics.

XSL and CSS are different because XSL uses XML notation, whereas CSS uses its own. Most modern web browsers support both languages, and the industry and W3C seem to indicate that it is necessary to continue the support for both. Each language seems to be able to cope well with different functions - it's even possible to use both languages; XSLT on the server to take data from a larger XML source, and compress to a smaller XML file to transfer to the client machine, and then CSS to style this data on a website, or web based interface.

XSL can be used both server-side and client-side, so it is down to the developer to choose when to implement the file. Developers should look into both the pros and cons for each of these options however, as various combinations of converted files can leave the source code a mass of FONT and BR tags, echoed directly from the XSL/XML mix up which could be created.

………………………………………………..
Avoid Common XSLT Mistakes - By: Jamie Simpson


Many common XSLT mistakes can often be avoided by using a good XSLT editor. There are several good ones around. Some of them are free. But if you are old school and like to hand code then look out for the following common errors that many programmers make.

Stay away from disable-output-escaping. This is for experienced programmers and even they are reluctant to use it 99 percent of the time. If you're modifying code and see disable-output-escaping being used then you can be sure the author did not know what he was doing. In 2.0 disable-output-escaping it is depreciated and processors no longer support it.

The next common error is using relative paths. The most common mistake is to use an absolute path within a loop. Paths need to be written starting from the context node. This is a must if you want to avoid a lot of errors. Remember relative paths should be preceded with "~/". Another common problem with relative paths happens when including and exporting to Java. When loading as a stream source if you do not set the system ID the processor does not know where the XSLT is and cannot resolve relative paths. By setting the system ID in a stream source you're telling processor where the commonFooter.xslt is located. After this is done double check that you're actually using the right path with your XSLT editor. This is a crucial last step. You'd be surprised how many errors can be eliminated by double checking the path. This is just a good programming habit too.

Everyone makes mistakes with namespaces. There are no easy answers. Make sure your elements are in the right namespace. Understanding that every element has a name which compromises a prefix and that all elements own their namespace node is best. This will help you to understand the various instructions and how they work together in the result tree. This takes care of most problems that arise with namespaces.

It is highly recommended to use an XSLT editor and avoid coding by hand. This alone will cut down on many errors. As mentioned above there are several good ones. Stylus Studio's editor is feature filled. There is also XMLSpy editor. If you want to develop quick error free style sheets than either of these two will do the job.

If you're just starting out Treebeard will fill your needs and it's free.
…………………………………………………………………………………………………………………………………………………………………