Client-side or server-side XML parsing?

[noodle_variation_187-X]

I want to populate a JSP website with textual content from a XML file, but I don't know if it is better to parse the XML on the client-side or on the server-side. Which option is better?

[Tolls]

Where's the XML?
If it's on the server then is the amount of data (ie size) you have after transforming it into whatever format you want to display less than the XML file or more?

[noodle_variation_187-X]

The XML is located on the server and it's used to fill the JSP pages with textual content. The parsing could be done client-side with JavaScript or server-side, but I don't know which approach is better.

[Tolls]

So that leads to point 2.
Is the data the XML is turned into (HTML tags etc) more or less than that held in the XML?
Would translating on the server require too large an amount of resources (ie memory) under high load?

And so on...

Personally I'd do it on the server unless doing so was unscalable...that is, you can't stream the result directly to the client without having to hold it in memory.

[jlczuk]

Not to contradict Tolls, but XML processing can be expensive (in terms of usage of compute resources) and can contribute to scaling problems if you are do this in high-volume requests. It isn't just a matter of the size of the XML vs. the size of what the XML is used to create. Depending on the circumstances, you can think of the clients as a gang of distributed parallel XML processors. Doing it in the client enables you to push that compute burden out of your server.

If the XML is being used to pass name/value pairs types of data, of constructs of the same, you might consider using JSON instead.

[Tolls]

Which is one possibility to where I was heading.
But the OP wasn't exactly open with the requirements.

If your XML and XSLT's aren't convoluted mushes that will require the full loading of the XML into memory in order to parse and transform then the footprint would be negligible.
If the XML is a single hefty file containing static text used to fill in the page, including stuff that may not be included in any one particular page, then dumping this onto the client each time may not be a good idea (as well as being a potential security problem, who knows).

Without knowing what the OP is doing, making any concrete suggestions without huge caveats (eg my "unscalable" one above) is not actually possible.

[noodle_variation_187-X]

Ok, thank you. So in case of doubt it is always better to parse the XML on the client-side. Is there any XML parser that can be recommended?

[Tolls]

I would disagree.
But without any idea what your requirements are I really couldn't say.

[noodle_variation_187-X]

Thanks for all your answers.

The XML file shall contain data about different countries (including tags for the name of the country, the gross domestic product, a textual description, area, population etc.). Basically, the content should be similar to a small wikipedia article.

Another question is, if it is better to build such a small projekt with JSP or JSF. Of course I have read articles about both of them and I know that JSF is based on JSP, but I am not sure if it is advantageous to start with JSF after having read the JSP basics.

[Tolls]

The pros and cons of XML apart serverside is the only practical option. If you process the XML clientside, assuming no XSLT, you will need to do so using clientside scripting (usually JavaScript). You will also need to instantiate an instance of an ActiveX control (eg: XMLDOM). This puts you at the mercy of individual browser settings. JavaScript and ActiveX can be switched off at the client and there is nothing you can do about it. If you parse the XML serverside you don't have to concern yourself with these sorts of issue. As for XML and XSLT generally, it was originally designed for platform independant inter system data transfer. I wouldn't use it for anything else.

Only if you're using an old browser (eg IE5 or 6).
Anything post that has a built in parser.

And as for the potted history of xslt, that's not actually correct. Yes, it is used for that, but that was not the only reason XSLT was created. It was reated to (not surprisingly) allow transformation of the raw XML data, which is not necessarily easily readable, into a more useable format, which not only covers useable by another system, but also useable by humans. So transforming XML data into reports, for example. Providing mutliple stylesheets for different output formats has been one of the most common uses of it since its creation.

[Tolls]

But that, presumably, would be down to the developer (him up there) to determine.
In any case I do agree, it's not something I would like to fob off onto the client, so it's a bit moot in that respect, but I do see it as a tool for basic reporting. After all, if you already have the data then an xslt is pretty easy stuff to put together to produce email, html, or whatever versions. Saves turning it into objects and feeding it to, say, velocity.

[nicephotog]

unless doing so was unscalable...

Browser javascript support versions and platform differences are untolerable. Sever side only!