Slashdot Mirror
Mozilla + CSS + XML = Structured, Formatted Content
Saqib Ali writes "Publishing XML content on the web requires some heavy processing on the server. There are many publishing framework (AxKit, Cocoon, etc) available in the market. However they are very CPU intensive. Apple's Internet Developer has a article on how to use CSS along with your XML content to render the formatted content in the Mozilla Web browser. It is very interesting read, especially for people who want to start creating content in XML, but don't want to invest in a expensive processing server/application. They have a nice example of RSS feed (XML) formatted for publishing in the browser."
Not off topic in the least. Slashdot uses antiquated HTML and CSS. It has no reason to use javascript on the front page. It uses tables for layout, when paragraphs would serve, and <img> when background-image would serve. Contextual markup would make the page more accessible to every sort of device, including PDAs and cellphones. Slashdot should move to XHTML 1.1, which is an application of XML.
There's more, but I thought "for slashdot?" would be quite succinct. If nothing else, slashdot could cut its bandwidth usage in half, and serve the exact same HTML for the "light" and full-bloat^Hn themes.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
The link mentioned doesn't work well in Mozilla 1.2.1: no hyperlink.
;
And konqueror can't even render the page. It says its invalid:
XML parsing error
fatal parsing error: the document is not in the correct file format in line 6, column 37
<link>http://www.scottandrew.com</link>
^
DNA is the ultimate spaghetti code.
I thought the idea of XML was really to keep it server side...u know this whole platform independant thing they've been working to for ages? Dont wanna sound like a flamer but it seems pritty stupid to start the "oh you need this browser to view this site" wars again. Had enough of that in ye-olden days of NS vs. IE :)
"What do you mean you have no ice? Do you expect me to drink this coffee hot?" - Random Customer, Clerks
Check out the serialization engines (Xml.Serialization) in .NET (or Mono for that matter), they're great. They can easily serialize any objects to XML and deserialize them as well.
.NET for your needs, checking out how the serialization works might help you to write your own routines.
While you might not be able to use
Hope that helps...
What matters to users isn't how many CPU cycles transformations take, but how fast they are. In many cases, using a bit of CPU on the client will lead to a much faster transition than retrieving a complete new page from the server (after having the server's CPU do the same work).
However, it's worth noting that it's probably a bad idea to send large amounts of data in XML formats without known semantics over the web. Semantically rich formats such as (X)HTML, MathML, etc., can be interpreted better by user agents other than those the author intended them for (e.g., cell phones with web browsers, speech web browsers, search engines), while formats such as XSL-FO or some custom XML vocabulary used within a single application for data storage can't be interpreted nearly as well on such devices. I have mixed feelings about relaxing this guideline for interactive applications, although I think if the interactive applications are generating their output on the client side in a format with known semantics then most of the problems go away, although the chances that the formats will continue to work for a long time in the future might be diminished.