Khun Yee Fung

Ok. I got it. This is the XSLT document I have to output carriage returns you need.
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" indent="yes"/>
<!-- start at the document root -->
<xsl:template match="/">
<!-- select any element that follows
the 'item' element and output it's name -->
<xsl:for-each select="/order/item/following::*">
<xsl:value-of select="name()"/><xsl:text>
</xsl:text>
</xsl:for-each>
</xsl:template>
<xsl:template match="text()"/>
<!-- appears to be redundant -->
</xsl:stylesheet>
The second template is redundant because you never allow XSLT to leave the template matching the root of the document. So it is redundant. In general, it is a dangerous template to be around, as it gets rid of all character data, if you are not careful.
So, do use xsl:text as is shown above.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Hmmm... you don't see the carriage return you have included by using xsl:text as well? Or you just don't see the linefeeds for using the entity &#xA; only? If you want to preserve the white spaces contained in an element, you can use the xml:space attribute (in this case, as an attribute of your xsl:value-of element). as well.
I used XT and Saxon to try something similar to the code you included here, and both gave me too many linefeeds...

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Usually, you force some text to be output by using xsl:text. Care to include a snippet?

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Well, apparently UBB is too intelligent to change my &#38; to & in my post. So,
"At least one cell phone do not support & as part of a URL in WML, so we have to hack it to make sure the character & is used."
should have been:
"At least one cell phone do not support &#38; as part of a URL in WML, so we have to hack it to make sure the character & is used."

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Well, the first XSLT processor we used was LotusXSL, now called Xalan. I used Saxon for command line checking quite a bit as well. Then I started using XT. I have not stopped using it. We even used it for generating WML and HDML (no kidding!) for some cell phones, with the output engine modified a bit to support <xsl:output method='wml'/> and <xsl:output method='hdml'/>. (At least one cell phone do not support & as part of a URL in WML, so we have to hack it to make sure the character & is used.)
If you are interested in knowing where XT is going, go to http://www.4xt.org. James Clark does not support XT any more.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

I forgot to mention that after you have generated an XSL document, you still have to render it into something much smaller in size. In other words, you want to render the XSL file into a document using a final format (e.g., PDF, PS, ASCII, HTML).
This is analogous to rendering SVG documents into GIF or JPEG images when you have to transmit the images described by the SVG documents over a network.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Well, I am going to use a slighty different format for the promotions. Quite similar, really. This is not a crucial point, anyhow.
An example of a book promotion is:
<book day="13" month="3" year="2001" status='Confirmed'>
<bookTitle url="http://www.amazon.com/exec/obidos/ASIN/0201711036/ref=ase_electricporkchop/107-0402457-1632559">XSLT: Working with XML and HTML</bookTitle>
<author name='Khun+Yee+Fung'>Khun Yee Fung</author>
<publisher url="http://www.awl.com/">Addison-Wesley</publisher>
<forum forum='XML,+XSL,+DOM+and+SAX'>XML, XSL, DOM and SAX</forum>
</book>
For a voucher, an example is:
<voucher day='20' month='02' year='2001' status='Completed'>
<title url="http://suned.sun.com">Sun Certified Java Architect Exam(voucher)</title>
<publisher url="http://suned.sun.com">Sun Educational Services</publisher>
<forum forum="Architect+Certification">Architect Certification</forum>
<winners>
<winner>Bidyut Padhi</winner>
<winner>faisal mahmood</winner>
<winner>shailesh sonavadekar</winner>
<winner>Vishakha Ahuja</winner>
</winners>
</voucher>
The root element for each kind of promotion is different. Again, this is to make it trivial to figure out whether a promotion is about a book, a certificate, or a voucher. In fact, later on, it could be something else. In this way, you can add in different kinds of promotion without rewriting much of the XML documents and XSLT documents.
Since I changed the XML format, I guess I should provide the XSLT documents as well. Actually, I will provide one. The other one is very similar.
Now, let us look at the XSLT document for past winners. It is good it has an xsl:output element. Since the method attribute is set to html, all the BR elements will be output properly. However, I would not set the doctype-public attribute because I believe your output will be only a fragment of the HTML document it is inside. Furthermore, I would set the indent attribute to yes only when debugging the output. Otherwise, I would set it to no. I don't want any browser to mis-interpret any whitespaces, something that the browsers do not handle well.
Now, suppose the lineup file looks like:
<lineup>
<promotion date='20001128'/>
<promotion date='20001219'/>
<promotion date='20010102'/>
<promotion date='20010109'/>
<promotion date='20010116'/>
<promotion date='20010123'/>
<promotion date='20010130'/>
<promotion date='20010206'/>
<promotion date='20010220'/>
<promotion date='20010227'/>
<promotion date='20010306'/>
<promotion date='20010313'/>
<promotion date='20010320'/>
<promotion date='20010327'/>
<promotion date='20010403'/>
</lineup>
I will keep the template that matches the root of the document:
<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>
I need a template to match the lineup element, so I use what Carl has written for matching 'BookPromotions' as the base. Now, the whole XSLT document looks like:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method='html'/>
<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="lineup">
<TABLE BORDER="1" CELLPADDING="5">
<TR BGCOLOR="#dec7a4">
<TD>Starting Date</TD>
<TD>Book</TD>
<TD>Author(s)</TD>
<TD>Publisher</TD>
<TD>JavaRanch Forum</TD>
<TD>Winners</TD>
</TR>
<!-- to handle each promotion -->
</TABLE>
</xsl:template>
</xsl:stylesheet>
No big deal.
Now, we have to write a template to match promotion. Let us do it bit by bit.
<xsl:template match='promotion'>
<!-- the body of the template-->
</xsl:template>
First, we have to read in the XML document corresponding to the date. This is done by using the document() function in XSLT:
document(concat(@date, ".xml"))/*
There are two ways to handle this external file. One is to use apply-templates to handle the nodes inside. The other is to keep the root element of the document in a variable:
<xsl:variable name='dateTree' select='document(concat(@date, ".xml"))/*'/>
From now on, you can use expressions like $dateTree/@status if you need to find out the status attribute of the root element. Notice that I used '*' because I don't want to know the name of the root element yet.
Now, we have winners only if the promotion is completed. To find out this is the case, we use the xsl:test element. If the condition is true, we output a row in the table. We will also output the date of the event as the first column:
<xsl:if test='$dateTree/@status="Completed"'>
<TR BGCOLOR='#eadbc4'>
<TD NOWRAP='NOWRAP'><xsl:value-of select='$dateTree/@day'/>/<xsl:value-of select='$dateTree/@month'/>/<xsl:value-of select='$dateTree/@year'/></TD>
<!-- the other columns -->
</TR>
</xsl:if>
Now, the title of a promotion depends on the kind of promotion it is. The name of the root element of the promotion document tells us what kind of promotion it is. So we simply apply the right templates for the root element of the document:
<xsl:apply-templates select='$dateTree'/>
And we need one template for each of book, giftCertificate, and voucher. And then we can output the other columns of the row.
First, the template for a gift certificate:
<xsl:template match='giftCertificate'>
<TD NOWRAP='NOWRAP'>
<xsl:value-of select='title'/>
</TD><TD> </TD><TD> </TD>
</xsl:template>
Nothing to it.
The template for a voucher looks like:
<xsl:template match='voucher'>
<TD NOWRAP='NOWRAP'>
<A HREF='{title/@url}'><xsl:value-of select='title'/></A>
</TD>
<TD> </TD>
<TD NOWRAP='NOWRAP'>
<A HREF='{publisher/@url}'><xsl:value-of select='publisher'/></A>
</TD>
</xsl:template>
Again, nothing to it, except the funny {publisher/@url} thing as the value of the HREF attribute. Well, this is an example of an attribute value template. In essence, XSLT allows you to specify the value of an (usually non-XSLT) attribute by enclosing an XPath expression in curly brackets (braces). The long hand for the A element above is:
<A><xsl:attribute name='HREF'><xsl:value-of select='title/@url'/></xsl:attribute><xsl:value-of select='title'/></A>
Of course, attribute value templates are much shorter in general. But it does test your understanding of XPath and location paths though.
Ok, finally, the template for a book promotion:
<xsl:template match='book'>
<TD NOWRAP='NOWRAP'>
<A HREF='{bookTitle/@url}'><xsl:value-of select='bookTitle'/></A>
</TD>
<TD NOWRAP='NOWRAP'>
<A HREF='{concat($common/author/@prefix, author[1]/@name, $common/author/@suffix)}'><xsl:value-of select='author'/></A>
<xsl:for-each select='author[position() > 1]'>
<BR/><A HREF='{concat($common/author/@prefix, ., $common/author/@suffix)}'><xsl:value-of select='.'/></A>
</xsl:for-each>
</TD>
<TD NOWRAP='NOWRAP'>
<A HREF='{publisher/@url}'><xsl:value-of select='publisher'/></A>
</TD>
</xsl:template>
Again, the only funny thing is:
{concat($common/author/@prefix, author[1]/@name, $common/author/@suffix)}
Well, I cheated a little bit. I have to get the elements in the common file somehow. What I did was to add an element at the top of the XSLT document in this way:
<xsl:variable name='common' select='document("common.xml")/*'/>
That is why I can use the variable called common.
The whole expression says to concatenate the prefix attribute of the author element of the element stored in the common variable with the author name and the suffix attribute of the author element of the element stored in the common variable. Quite a mouthful, but rather straightforward.
Another thing: I separate the first author name with the other author names because I want to have a BR element only between author names. I don't want a BR element at the end of the list of names.
With the three templates out of the way, the template of the promotion is not mysterious any more. This is the whole template:
<xsl:template match='promotion'>
<xsl:variable name='dateTree' select='document(concat(@date, ".xml"))/*'/>
<xsl:if test='$dateTree/@status="Completed"'>
<TR BGCOLOR='#eadbc4'>
<TD NOWRAP='NOWRAP'><xsl:value-of select='$dateTree/@day'/>/<xsl:value-of select='$dateTree/@month'/>/<xsl:value-of select='$dateTree/@year'/></TD>
<xsl:apply-templates select='$dateTree'/>
<TD NOWRAP='NOWRAP'>
<xsl:choose>
<xsl:when test='not($dateTree/forum)'>
 
</xsl:when>
<xsl:otherwise>
<A HREF='{concat($common/forums/@prefix, $common/forums/forum[@name=$dateTree/forum/@forum]/@number, $common/forums/@suffix)}'>
<xsl:value-of select='$dateTree/forum'/></A>
</xsl:otherwise>
</xsl:choose>
</TD>
<TD NOWRAP='NOWRAP'>
<xsl:value-of select='$dateTree/winners/winner[1]'/>
<xsl:for-each select='$dateTree/winners/winner[position() > 1]'>
<BR/><xsl:value-of select='.'/>
</xsl:for-each>
</TD>
</TR>
</xsl:if>
</xsl:template>
The other XSLT document is quite similar. I will leave that as an exercise.
Oh, below is the whole common.xml file. Obviously, I don't have the full set of forum numbers for JavaRanch. I just inserted enough to handle the promotions.
<common>
<author prefix='http://www.javaranch.com/cgi-bin/ubb/ubbmisc.cgi?action=getbio&UserName='/>
<forums prefix='http://www.javaranch.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum=&number=' suffix='&DaysPrune=1000&LastLogin='>
<forum name='Servlets+and+JSP|APO|s' number='7'/>
<forum name='Star+Office,+et+al.' number='14'/>
<forum name='Java+in+General+(beginner)' number='33'/>
<forum name='Java+in+General+(advanced)' number='34'/>
<forum name='Performance' number='15'/>
<forum name='XML,+XSL,+DOM+and+SAX' number='31'/>
<forum name='OO,+Patterns,+UML+and+Refactoring' number='9'/>
<forum name='Other+Java+APIs' number='45'/>
<forum name='Architect+Certification' number='26'/>
<forum name='Process:+UP,+RUP,+DRUP,+XP,+etc.' number='42'/>
</forums>
</common>
Now, we are back to the beginning. Like Carl said, what is the next step? Well, for these two pages, there is really not much else that you want to do, other than setting up a batch file so that whenever you finish generating the HTML pages, you move them over to the place where their JSP pages can pick them up.
These are the files I have: common.xml, the individual promotion files, winners.xsl, and lineup.xml. No idea how to send them over if you want them.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

More specifically, XHTML 1.0 is HTML 4.0 in XML. XSLT, on the other hand, is a programming language that transforms XML documents into other documents, whether they are XML, HTML, or text.
XSL Formatting objects (XSL-FO, or simply XSL) is an entirely different animal: it is a markup language for the description of document layouts. You can think of it as Postscript without the programming primitives. It is almost like PDF but of course it is not a final format. PDF is a final format for documents; documents in a final format are not supposed to change much.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

The XML specification specifies a set of rules for you to define classes of XML documents. One class of XML documents might be good for a certain thing, like SVG (scalable vector graphics) is good for describing vector graphics, obviously. XSLT is actually a programming language that is specified as a class of XML documents. XHTML 1.0 is a class of documents that is almost identical remapping of HTML in XML.
On the other hand, HTML is a class of documents specified using SGML.
If you want to compare HTML to something, you ought to compare HTML with XHTML, then you would be comparing two classes of documents that are meant for the same purposes. XHTML will continue the evolution of hyper text markup started by HTML.
XML is a subset of SGML so I guess comparing SGML and XML is only useful when you are talking about pragmatics of the two.
So, XML and SGML are one order above HTML and XHTML.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Oh, ASN.1 stands for "Abstract Syntax Notation Number 1". It is used to specify the format of structured binary data. It has a few "transfer rules" like BER (Basic Transfer Rules) that determine how a chunk of data using ASN.1 can be transferred from one application to another. It is being used right now by LDAP and SNMP to specify their data formats, for instance. Before ASN.1, you could either use ASCII to format data (using base64 or uuencode if you have to), or you use a proprietary format. Both unsatisfactory.
Think about the message format of FTP, which is an example of ASCII message format. Or the message of DNS, which is an exmaple of a binary format.
However, with XML, you can avoid ASN.1 altogether for textual structured data.
Anyhow, a bit offtopic...
------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

This is what I would do. First, I would use one file for each book/promotion item. Second, I would use a lineup file to include only those that I would like to include on those two pages.
The reason is that once the single XML file becomes bigger it will become quite difficult to handle. If you have a separate file for each book, then they become the de facto archives for you anyway. With the lineup, you can pick the ones that need to be included.
Say, the following book (guess which one I chose) will be in a file called "20010313.xml".
<promotion>
<date>03/13/2001</date>
<book url="http://www.amazon.com/exec/obidos/ASIN/0201711036/ref=ase_electricporkchop/107-0402457-1632559">XSLT: Working with XML and HTML</book>
<author url="http://www.javaranch.com/cgi-bin/ubb/ubbmisc.cgi?action=getbio&UserName=Khun+Yee+Fung">Khun Yee Fung</author>
<publisher url="http://www.awl.com/">Addison-Wesley</publisher>
<forum url="http://www.javaranch.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum=XML,+XSL,+DOM+and+SAX&number=31&DaysPrune=1000&LastLogin=">XML, XSL, DOM and SAX</forum>
<status>Confirmed</status>
<complete>false</complete>
</promotion>
The lineup XML file might look like:
<lineup>
<promotion date='20010313'/>
<promotion date='20010320'/>
<promotion date='20010327'/>
</lineup>
Now, how to construct the lineup file is really up to you. For instance, if you always have a book to promote for each week, and you want to show the most recent 10 weeks, then all you need is an element to specify the starting date and the number of weeks to cover.
Notice the lineup file I include here contains two dates that have not arrived yet. Well, you can specify whatever the behaviour should be when that happens. Since you will need the document() function to open the XML files, you will know whether a file has been successfully opened.
I would generate the two files offline and then get the JSP to include the HTML files generated. If you only have to worry about these two pages, this is all you need to do. In this way, the XML and XSLT files are safely in your own directories. You move the HTML files to wherever you have to.
A few comments about the XML: I would not specify dates in this way. I would use attributes and separate the day of the month, the month, and the year. Same idea with the book URL: if you have the separate elements that can be used to construct the URL, you might as well specify the data somewhere else. In this way it is not as easy to have an incorrect entry. In fact, I would combine status and completion together as well. Then, I would have an element called "winners" to contain all the winners.
The entry for my book would then become:
<promotion day="13" month="3" year="2001" status='Confirmed' complete='False'>
<book ISBN='0201711036'>XSLT: Working with XML and HTML</book>
<author name='Khun+Yee+Fung'>Khun Yee Fung</author>
<publisher url="http://www.awl.com/">Addison-Wesley</publisher>
<forum forum='XML,+XSL,+DOM+and+SAX">XML, XSL, DOM and SAX</forum>
</promotion>
And the common information is in the common.xml file:
<common>
<amazon prefix='http://www.amazon.com/exec/obidos/ASIN' suffix='ref=ase_electricporkchop/107-0402457-1632559'/>
<author prefix='http://www.javaranch.com/cgi-bin/ubb/ubbmisc.cgi?action=getbio&UserName='/>
<forum prefix='http://www.javaranch.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum=' suffix='&number=31&DaysPrune=1000&LastLogin='/>
</common>
You can provide the reference to the common XML in the lineup file, or you can hardcode that in your XSLT, or you can pass the file name of the common file in as a global parameter.
Another example of a promotion:
<promotion day='09' month='01' year='2001' status='Confirmed' complete='True'>
<giftCetificate>Amazon Gift Certificate</giftCetificate>
<winners>
<winner>Travis Gibson</winner>
<winner>Shaochun Xu</winner>
<winner>Justin Moore</winner>
<winner>Nancy Marik</winner>
</winners>
</promotion>
I wonder whether I can combine the status and the complete attributes too. The state transition might look like: empty -> pending -> confirmed -> completed.
My goals are: easy to process by hand and easy to avoid errors. But you might have a different set of criteria when you design your XML files.
Tomorrow, we will look at the XSLT files.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

XML is very important for a lot of reasons. It is like HTML; when people realized they could use HTML to publish pages of pages of information and almost everybody else on the Web can access them, everybody switched to HTML to publish information on the Web. Now, the Web is only one part of Internet. How about the other parts?
Well, XML is meant to be the HTML for a large chunk of the rest of Internet outside the Web, and also to replace HTML eventually as well. So, XML in itself is not important, like HTML in itself is not important. But if everybody is using HTML, you might as well use HTML. Same with XML.
I used to hope that everybody would use ASN.1 because it would save so much time when two applications need to talk to each other. With XML specified, I guess ASN.1 can keep doing whatever it is doing now...
Of course, you don't have to know HTML before you learn XML. In fact, doing it properly, HTML is actually harder than XML.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Well, let me dream a little bit about what XML databases can look like. Of course, it is not going to happen for a while yet. Still, it is good to dream a little bit sometimes.
We can certainly have an XML database that is based on a hierarchical database management system (eXchelon, an XML databse, the last time I looked, used ObjectStore as its native database). How the XML data is stored is not important for us here. As long as the data is stored somehow in an efficient way, that is good enough.
If you need industrial-strength database management stuff, build it in. I will talk about what the database can do later on.
Now, how do you connect to such a database? Well, you can specify a URI, no? For instance, suppose you have an XSLT stylesheet that you want to apply to an XML document stored in an XML database. You might specify something like http://www.xmlstoragedatabase.com/personnel.xml. Mind you, you are not getting the whole XML document back, because you don't need to (hereby solving one of the criticisms on XML data).
With XSLT, that is all you need. When you issue an XPath expression against the XML "document", the XML database executes the XPath and returns whatever is necessary to you. So, your XSLT stylesheet processes merrily away, without knowing that the XML document is actually in an XML database,as there is no difference between that and an XML document sitting in your file system.
But what if you want to manipulate the XML data in the database? Well, XML Query is coming soon, I hope. With that language, you essentially have a SQL for XML. Do whatever queries you need, do whatever updates you need, all in XML.
But, how do we ensure the XML database's integrity is maintained? Well, that depends on how you describe the data in the database in the first place. I am not sure whether XML Schema allows you to specify referential constraints, etc. But I don't see why it can't be done somehow, through XML schema or not. Same with indexing, etc. So, you can build a very tough and scalable database for XML documents. It is not going to happen overnight, as relational databases did not become "fashionable" overnight either.
Relational databases are really not the best way to handle hierarchical data, as XML documents inherently are. So I don't see why we cannot have XML databases and relational databases coexist peacefully together. In fact, they will probably be supported natively by the same database management system later on, when XML Schema and XML Queries mature to the stage that they can be used as the solid foundation for such a database.
A side note on XSLT's need for getting whole XML documents: in general, XSLT stylesheets do not traverse an XML document fully. It might, but it does not have to. However, it does need something like random access to the document. This is the reason why many XSLT processors have to keep the whole XML document in memory. But this is really equivalent to having a in-memory XML database.
------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

I am not sure whether this is one of the goals of XML; I doubt it is. However, XML turns out to be extremely useful for data that are hierarchical in nature. The data do not have to be trees, as long as they are hierarchical. These data are not as easy to store as tables. And when they are stored as tables in a relational database, the access and manipulation of them are not as easy as it takes a bit of time to reconstrct the hierarchical nature of the data from the tables.
Secondly, XML documents are easy to extend. When you design a relational database, it is not easy to migrate to a different data schema. So, you tend to think much more about the data before you commit the design. In XML, if the data is hierarchical, adding a new element somewhere is not a big problem.
Remember, the fact that the data you see is in XML does not mean that it cannot be processed and stored in a different paradigm entirely. For instance, the last time I looked at eXchelon XML database, they used an OODBMS as the actual database but with XML and XSLT as the front end.
Of course, there are aspects of XML that have been totally overblown. For instance, many people say XML is good because the element names are in English. That is of course assuming that yu can read English. And when somebody from Japan is designing a DTD, he/she can easily assign the element names in Japanese, as XML names can be in Unicode. So, the fact that an XML can be readable to somebody does not mean that it will be readable to you, unless you happen to know the language used in the document. Also, sloppy designers can always chose completely inappropriate names as well.
But there is really no alternative if you want a (almost) univerally acceptable data format that is powerful enough to handle almost all structured data.

------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML

Quite a few companies are doing exactly that. I can't comment on how they do it; but this is the general idea. First, define the data you want to publish in XML. Then, find out the parameters of the displays of the devices you want to publish to. As you can imagine, HTML and WML are very different animals, and you will need at least two separate sets of XSLT stylesheets to handle them. Since the devices supporting WML are also quite different in attributes (number of lines, number of columns, fonts supports, imagines supported), in general, you need to program your XSLT well to be able to add more devices without rewriting your WML XSLT stylesheets.
Enough general comments. A bit more specific now. The biggest problem with publishing things that you usually publish with HTML is that they are quite verbose. This is not a good attribute for cell phones, as you can imagine. Think hard about the DTD that will handle both the more verbose HTML site that you are going to publish your information, and also the severely limited text display capabilities of the cellphones and such. Get that done first.
Doing the transformation for some specific devices is not very difficult. The difficult part is how to write your stylesheets so that you don't have to modify them too much when you have another new device to support.
The biggest non-programming issue with multi-device publishing is the usability issue. WML sites are not easy to design well, in terms of usability. I would spend quite a bit of time to make sure the WML sites are acceptable for the devices supported.
I think you will need Java to coordinate the different stages of the publishing process, especially if you want to generate the pages on-the-fly.
Without giving you a technical proposal, this is what I have:
1. Design a DTD that is acceptable for both HTML and WML sites. For HTML sites, you want to display more information so that they don't look bare. But for WML sites, you want to make sure whatever you have is to the point and useful rightaway.
2. Design two or more sets of XSLT stylesheets for HTML, and also for WML devices you have to support. If you decide to write one set of XSLT documents for each device, that is good too. Otherwise, the set for WML will have to be quite flexible to hande most WML devices.
3. Use your servlets, JSPs, whatever to detect the device from the HTTP requests.
4. Apply the appropriate XSLT documents to the appropriate XML document to send out as reply.
Now, this is still very vague, of course. But it can't get much more specific than this right now.
------------------
Khun Yee Fung
Author of XSLT: Working with XML and HTML