Dmitry Kirsanov

Congrats to the winners! Hope you enjoy my book!

Daniel: <xsl:for-each select="."> iterates only once, probably it's not what you have in mind. Make a template with match="comment()", and then inside the /project/target template, call it thus:

<xsl:apply-templates select="comment()">

No need to do any for-each; this will run the comment template on all children of the current node for whom the value of of comment() is true, i.e. for all comments.

Pradeep: in fact most XSLT implementations are written in Java: Saxon, Xalan, XT, jd-xslt...

Dmitry: XSLT is a programming language, so the question of "what XML is best for XSLT" has only one answer: that depends on how you program your stylesheet. The only requierement is that the source is well-formed so it can parse; other than that it's up to you. Your starting point is the structure and meaning of your data; design both your schema and your XSLT to best fit the data, not each other.

Yes, it is almost always a good idea. And yes, performance may be a problem, but it's rarely such a big problem as it is sometimes presented. See this thread for a discussion:

https://coderanch.com/t/126838/XML/Dmitry-Kirsanov-XSLT-value

The definitive (but easy to understand) grouping examples are right here:

http://www.w3.org/TR/xslt20/#grouping-examples

Basically, the grouping feature may be called "for-each on steroids". The new instruction, for-each-group, works similar to for-each, but on each iteration it gives you a group of nodes instead of a single node. This group, accessed by current-group() in XPath, can be further sorted, filtered, transformed, etc. The best thing about that is that the groups may be selected based on a wide variety of tests, such as common value, adjacency, starting/ending node etc.

> my question is if xml use to store data, XSLT use for present data, do you > think xml should store database's data as a good idea which allow minimise > the database processing and hence benefit better speed for application ?

You can store all your source data in XML, but it likely won't give you any speedup. On the contrary it may be significantly slower. The advantages of XML are different: it's a human-readable, easy to define and validate interchange format which is therefore good for connecting different modules (such as the dynamic engine and the presentation layer), but not necessarily the best for using internally in a module.

> another question is , will XSLT present data in standard view format in different browser ?

XSLT will produce whatever you program it to. This can be HTML 2.0, MSIE HTML, XHTML. It may be even plain text of a Windows INI file if you need them.

You can generate comments using XSLT using the xsl:comment instruction. Or, if the SSI comments are in your XML source, you can match them using comment() and pass unchanged to the output, for example:

<xsl:template match="comment()">
<xsl:copy/>
</xsl:template>

First of all, if you're passing a bunch of data that is to be presented as a web page, it's unlikely that you'll need a 1000-node tree because web pages should never be that huge. A complex page may have lots of nodes in its XHTML representation, but most of these are formatting, while the dynamic data it gets from the engine is usually much smaller.

Also, there are different options for communicating between a data engine and the formatter. If DOM trees are too slow for you, you can use SAX streams (the approach utilized by Cocoon). Besides, in some cases even serialized XML that is re-parsed by the XSLT processor may be fast enough.

> But isn't it also job of programmer and designer to provide the user with a
> responsive application. Aren't those xml-serialiazation/deserialization
> stuff processes which slow down system heavily?

Performance is only one aspect of a good application. Maintainability and clean design are just as important. What's the use of fast response times if the application is a mess? Besides, the notion of XML always being a bottleneck is an exaggeration. It is usually possible to find a good middle ground between speed and elegance.

Separating data structure and presentation is a must if you want to stay sane and scalable, and to implement such separation, you either go with XML (a standard, well supported way) or you reinvent the wheel yourself (an inevitably limited, even if potentially more performant approach). Don't fall into the premature optimization trap.

Use xsl:copy-of instead of xsl:value-of.

> But, why would you use XSLT to display your data within a typical web
> application? Do you go through the extra step of creating an xml document
> out of raw data from a database just to use xslt for your presentation?

Very good question, thanks!

No offence, but it seems to me that this question shows your programmer's bias As a programmer, you see the problems that come with retrieving and processing data, but fail to see the problems associated with presenting that data. In other words, once your business logic has successfully finished, you consider the task fulfilled and the rest trivial, right? Not even close.

As a designer, I have another perspective on the whole story. From my viewpoint (of course I'm now exaggerating for the sake of the argument), it's the programming logic that is the easy part. Just run a database query and do some calculations - that's pretty straightforward. But then comes the really difficult part: we need to show the output data to the user in the most unambigous, logical, consistent, and helpful way. There's a lot to it, but the most important prerequisite is that the data I (as a designer) am working with is itself unambiguous, logical, and consistent.

And this is where XML enters the play. XML is, basically, a formalism for consistenly naming things; you see some entity, you tag it with a name that fits it. (Usually, in the process of such naming you also discover lots of problems with the consistency and logic of your data.)

Now the importance of XML in web development should be obvious: It is a common language that lets programmers send their data to designers, without each stepping on the other's toes. You (the programmer) are relieved of thinking about <td>s and <tr>s and spacers and images; you just give me your data and explain (using XML) what part of it is meant to be what. I (the designer) an relieved of thinking about how or where from this data came to be; I just take it and transform it into a presentation. Apart from being a language of communication, XML can also serve as a checkpoint which lets you make sure that the data you produce makes sense, and which lets me make sure that my transformation and presentation algorithms are indeed a good match for this data.

So, to put it simply, XML is the best way to keep sanity and maintainability of any reasonably complex information processing system, and a web application is certainly one of the model showcases for XML and XSLT. It may seem unnecessary at first, but if you actually try it you'll realize how much more elegant and modular the system becomes - and how many problems it had before

I also want to add that the programmer's viewpoint on web development is absolutely dominant in books and online writings on this topic, while a designer's perspective has much smaller presence, and an integral view that recognizes the importance of both parts of the equation and the role of XML connecting them is even rarer. This was one of the main motivations for writing my book.

Basically an XSLT stylesheet is a set of rules for transforming one kind of XML to another kind of XML or an arbitrary textual format. Nothing more, nothing less. However this simple description fits a huge number of practical scenarios, and the deployment approaches will vary correspondingly. For example, you can run an XSLT program as a standalone conversion utility, or you can install it on your web server to generate HTML pages, or you can run it from a Java program by interfacing with an XSLT processor. In all these cases, however, the actual XSLT stylesheet may be the same, which underscores XSLT's strong points of portability, laconicity, and high-level declarative programming style.

Stylevision is, in a way, an extremity; it's really only useful for XML-to-HTML kind of XSLT, and the results from its drag-n-drop sessions are usually very rough and only usable as a starting point for further refinement. If however what you need is source-oriented editing with additional XSLT-specific conveniences, then your choice is much wider and more meaningful. Oxygen, Topologi CME, Komodo are all worth checking out, plus you have XSLT plugins or modes for tranditional IDEs and text editors (jedit, Emacs). Altova's offerings are good too, though they have the disadvantage of being Windows-only, and in my opinion they don't have so much edge over the competition as to justify that.

I think the general idea is to use traditional databases when performance is critical and when all of your data has fixed structure. If however the human-readability and -editability of your data is important, and when the data structure is arbitrary within some limits, XML is a much better choice even though it may mean some performance loss. Note however that there exist XML databases that let you get the best of both worlds.

Josh: sorry but your question is really outside the scope of my book, or my experience for that matter I'm a XSLT person; try to get help from Java people on how to use Xalan/Xerces from Java.

Dave: It's hard to give recommendations without knowing your requirements in detail. It also depends on what approach to tools you prefer in general. For example I tend to be a minimalist, and most of the time the only tools I use are the text editor (Emacs) and the XSLT processor (Saxon). XSLT is really a very simple language, and helper or debug tools are rarely necessary. When you need them, however, there's the XSLT-process IDE right inside Emacs (which I quite like). Perhaps the most important feature for an XSLT programmer is the ability to run arbitrary XPath queries against your source; this feature is available in standalone utilities, shells (xsh.sf.net), and some XML-enabled editors.