| Part 1: Building an XML/XSLT/JSP based Newsletter |
| Casey Kochmer |
| Introduction: |
| At the JSP Insider site we are in process of switching over to XML based
data sets to drive building the site. Within this process the JSPBuzz
newsletter is also getting converted to be stored in XML format. This is
a start of a series of articles and it will cover the process used in using
XML, XSLT and JSP for the JSPBuzz. This first article is set up as an over
view of XML and XSLT. It will mostly be a high level discussion of what
is required to use XML/XSLT within a project. This first article is geared
toward both project managers and programmers just starting to think about
XML and XSLT. More experienced programmers will want to wait for the next
installment in this series. The next article will get into the coding and
show tricks and techniques to make using XML and XSL easier for the
programmer. Then the final article will show how to merge this with JSP and
how to use JSP as an engine to generate all the required documents using the
XML and XSLT.
|
| Impressions of Using XML and XSLT |
| XML has already proven itself within the technical community. The problem
with XML is not using it, but rather how to apply it. Converting data
into XML takes time and does require extra work. Quite honestly,
programmers and projects should not rush into using XML unless they
understand this fact. Lets use the JSP Buzz as an example. If the JSPBuzz
was purely just a newsletter, it would not have been worth the time to
convert it to XML! The JSPBuzz consists of many small articles which need
to be typed, formatted , proofed, and rewritten several times before a
final copy is produced to be sent to the readers. This multiple pass
process means it is easiest just to leave and write the JSP Buzz
initially as a text file. A text file makes life simple for the authors
and editors to quickly proof, edit and fix. After the JSP Buzz text file
is finished, the data from the newsletter needs to be entered into an XML
file. For the authors this is an extra step and extra time spent within
the process. If only a text newsletter is required, there would no reason
to spend the extra time to store the JSPBuzz data into an XML file.
However, lets examine the basic processes that the JSPBuzz
sits within for Amberjack software. The JSPBuzz is more than a
newsletter. Three different versions of the newsletter are used by
Amberjack Software. We send out one text based and have two online
versions. In addition, the JSP Buzz is used to feed links into our main
site. Finally, in the future we will be offering the JSP Buzz for other
sites to use as a newsletter. All this means of course, more work is
involved than just maintaining a single text file. This means, the extra
week or two spent in creating and tweaking the XML/XSLT formats will be
worth the time to convert the text based version into an XML data set.
Once an XML format exists, it becomes a relatively easy matter to create
different XSLT style sheets to drive out the multiple versions of the
JSPBuzz. Short term it is a pricey hit in time to convert and use XML for
the JSPBuzz, long term however, more time is freed up as the automation
of the multiple styles is now easy to achieve. Also we have the
capability to expand the newsletter for other vendors.
|
| First Step: Building an XML File layout. |
| The most important step is also the first step, building the layout for
your XML file. This will be similar to designing a small database. It
will become necessary to plan on this being a several step process really. |
| A) An initial design will be required to hold the data. This basically
means two different things. The first is most obvious, creating the layout
needed to hold the data. The second aspect required in the design are what
attributes are needed to support the destination layouts. Technically an
XML data file is just for storing data however, our newsletter has
additional meta data in the form of the layout. While The XSLT style
sheets represent the presentation layer, the style sheet still requires
clues for our XML dataset on how to format the data. For example, we store
position number of each link. This permits the XSLT style sheet to order
the links correctly relative to the display outlay we are interested in
showing to a reader. The other consideration is that design of the XML
data file should make it possible to only put content in the file. It
would be bad practice to include HTML formatting within the data. All
presentation logic should be performed within the XSLT style sheet. However,
in order to remove the need to embed HTML logic creates the need to include
some formatting attributes within the XML. |
| B) A data dictionary is required to define your data. In the world of XML
this means creating either a DTD or a Schema. While I recommend using a
Schema to define your XML file, a DTD was used for the first cut on the
JSP Buzz layout. DTD's are older and well established. Schema's are more
flexible and are in XML format themselves. |
| C) Enter data into the new XML files. The fact of the matter is that the
data still needs to be pushed into the XML file. While it would be nice to
automate the generation of XML files, many times it may not be practical.
Case in point is the JSPBuzz. A text file just is the most efficient
method to create, edit and modify the data for the initial creation of the
JSPBuzz. Some companies will want to build special interfaces to enter the
data to XML, others will opt to use an XML IDE. However, the generic XML
IDE's are still not quite easy enough to use for this purpose. |
| Now the fun part just begins for this is an iterative process. This means
during the next steps of building the XSLT style sheets new details will
be discovered by the programmer. So change and tweaking is an integral
part in creating the XML data format. As a result, it should be expected
that within the first part of your project the overall process will be
repeated several times as the design gets optimized to support various
destination clients. The good news is that each design change will get
smaller as time goes by, but the bad news is building the XML file is
not a single day project. Expect the XML design phase to last for the
first 2/3rds of the projects overall initial design stages. |
| Second Step:Using XSLT |
| The second step is easy from a perspective that XML style sheets for
formating XML data are being built. In a nutshell, the programmer is
using XPath as a language to parse their way thruogh an XML document and
convert it to a new document. Once built the XSLT document is reusable
and will be used to generate a HTML or text based output file. |
| That is all that is involved in the second step. However,it would be nice
to add a brief taste of the flavor of development happening within XSLT. In
projects like the conversion of the JSPBuzz, the use of XSLT is a server-
side process to occasionally produce HTML files on a need only basis.
Once built these file won't need much tinkering, however, the building of
the file is a slightly messy process. I recommend building these XSLT
style sheets in an onion like manner, in layers. The XSLT style sheet
will consist of many small templates to parse through the XML data. Don't
try to build everything in one pass. Instead build by groups of templates
and test. It makes building the XSLT style sheet easier and doesn't add
much time to the development. In the case of the JSPBuzz templates it
made life easier as many of the templates were reusable with slight
modifications.
|
| From this experience of building the JSPBuzz style sheets I would like to
comment on the fact that XSLT is an interesting beast. In some ways it is
very much like JSP since it uses layers of logic. With
XSLT the programmer will be weaving XML, XPATH and HTML together to
produce a final output. In some respects the JSP skills in combining
client and server side mixing will come in handy with using XSLT. Becuase
of this JSP programmers will have an easier time learning XSLT. The
biggest problem comes from the lack of solid tutorials and strong tools
to make life easier. |
| Third Step: JSP |
| Automate the processes with JSP. As a server-side tool, JSP is availible
for building the templates to pull everything together in a XML/XSLT
project. JSP is not only for building web applications, it is a tool for
generating data for a client. In our case we will use JSP pages to
generate our JSPBuzz pages automatically for the site. While the client
will be our own server, that still works as a client. Why use JSP?
Because JSP has a simple interface. Also as JSP programmers we still have
access to all of the Java tools which can build, modify and use XML in
any fashion. The goal is to minimize the amount of work we actually need
to perform, and reusing JSP is both easy and leverages a language we have
experience within. This makes it a perfect tool to automate the final
generation of the pages we need. |
| The last article in this series will show how to use JSP for automation of
the XML/XSLT processes. |
| Resources: |
|
| Getting Started using XML |
| W3Schools |
| This series of articles will not teach much about the XML portion
of the project, so if you need to learn more about XML basics
W3Schools is a great place to get started with XML. This site has excellent resources to help newer programmers
learn the basics of XML, DTD's and Schema's. |
|
| Getting Started Using XSLT |
| A list of resources which are helpful in XSLT. |
| XSLT poses a bigger problem for a programmer. Solid informational
resources are still few on the internet. To make things worse using XSLT
is a several step process. That is, in addition to the XSLT style sheet,
finding and learning how to use a XSLT template engine to run the XSLT
and XML together is also required to get a final results. |
|
|
| Mozilla Browser |
| The latest version of Mozilla browser has begun to incorporate XSLT
support within the browser. While this support is still sketchy, it bodes
well for the future as Mozilla gets expanded to work with XSLT in a more
complete fashion. I still recommend IE 5.5 as the perferred way to
test and use XSLT currently. |
|
| Tools |
| XML Spy |
| As a programmer I am not very happy about the selection of tools availible
to make my life easier using XML and XSLT. While it seems like many
software makers talk about how XML\XSLT is awesome, few high quality
tools exist. A text editor is still a good way to go for most XML work.
The one professional tool I have been using of late is XML Spy.
I will have a full review of this product in the next issue of the buzz.
In the meantime if you are looking for an XML IDE to help, it is possible
to download a fully function version of XML Spy which works for 30 days. |
|
| Conclusion:
XML and XSLT are a great combination of tools which come at a price of
building additional infrastructure. Using this pair of tools will greatly
expand the ability to reuse and reformat existing data. However, to
maximize the benefits means spending extra time up front to design the
framework on how XML and XSLT will be implemented for your project. Using
XML/XSLT is not just something that gets drop into a project, it is a
different way of thinking on how to make your data reusable within your
project. This means using XML and XSL will result in some modifications
in how a project's business model will work with the data.
The next article in this series will examine using XSLT in detail and
tricks and traps a programmer faces in XSLT. The article will also include
examples from the JSPBuzz newsletter which will give a template for
programmers to use in building their own newsletter. |