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."

Comments

*ahem*

[DarkVein]

tu slashdot?

Re:*ahem*

[DarkVein]

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.

web log analysis

[DeadSea]

I'm working on a some web log analysis software to license under the GPL. The output will be XML that is linked to CSS and Javascript. Besides being easily parsed by another program, the output is pretty, and the tables can all be sorted by any of their columns. It uses DOM Level2 functions called from MergeSort implemented in Javascript. Watch my website, I should have it done, or at least a first version within a couple weeks.

Moving processing from servers to clients?

[fredrikj]

Just when you think Phoenix has saved you thousands of precious CPU cycles over Mozilla, something like this pops up and fills the hole. Doh!

Re:Moving processing from servers to clients?

[Assimil8or]

This exampe works with Phoenix, too! =)
Even in Opera 7,.. IE (5) has some problems,.. ;)

Re:Moving processing from servers to clients?

[Komarosu]

IE 5.5 is fine here.

Re:Moving processing from servers to clients?

[dbaron]

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.

Bah. Boring. What's NEEDED is this:

[torpor]

What I need (as a C programmer) is a way of getting all the data structures in my program written out to XML, then sucked back in again.

Here's the caveat: Easily.

Surely someones' got some tools for taking C code-style structs and turning them into an .XML file somewhere ... but I'll be damned if I can find it. (libexpat is half-way there, but still a pain - writing handler functions for a parser is great and all, but ...)

All this talk of the wonder of XML and the benefits of using it as a store methodology is great and everything, but the 'ease-of-use' factor isn't really there with XML, as promised.

In the end, if you want to use XML programmatically, it's still just as much of a pain in the ass to use as if you were writing good-ol' C fread/fwrite-style save-/load-to-disk functions. The only difference is, with XML you get to read the results a little easier than raw binary structs written to disk.

If I'm clueless about these things please feel free to beat me with a stick. It's just that libexpat and the like are a *lot* of overhead for someone who just wants to be able to save and load data structures into an .xml file ...

Problems in Mozilla and Konqueror pre-3.1

[oever]

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&gt ;
^

Re:Problems in Mozilla and Konqueror pre-3.1

[palfrey]

I'm using Mozilla 1.2.1 (on W2K) and I'm not having any problems with the page at all - renders exactly as the image shows. Got some odd settings there?

Re:Problems in Mozilla and Konqueror pre-3.1

[oever]

The page renders fine on Mozilla 1.2.1, but there are no hyperlinks on the page.

On reading the article a bit closer:

As you can see, formatting XML with CSS is as simple as doing the same with HTML. But I have a problem: None of my links are actual links. That is, they don't behave as HTML links when you click on them. I need to find a way to transform the RSS LINK elements into working links. CSS is ill-suited for providing this kind of functionality, but I do have another tool at my disposal: DOM.

...

Loading the RSS file in Mozilla now produces the desired result: clickable title links. You can see a working example here, although you'll need Mozilla 1.0 or better to experience it.

Well, on my machine (SuSE Linux 8.0) Mozilla 1.2.1 does not show any hyperlinks. Also the titles are not rendered bold but plain.

Re:Problems in Mozilla and Konqueror pre-3.1

[vbweenie]

I wonder whether getting browser support for XLINK is the way forward here? Certainly writing script to manipulate the DOM to get your links is a clumsy approach; by the time you've done that, you may as well have written some XSLT and had done with it.

Re:Problems in Mozilla and Konqueror pre-3.1

[JQuazar]

Moz 1.2.1 on Mac OS X... no hyperlink joy here, either.

Re:Problems in Mozilla and Konqueror pre-3.1

[Rick the Red]

It says: "you'll need Mozilla 1.0 or better to experience it." I use Mozilla 1.0 and it works just fine for me. Clearly, Mozilla 1.2.1 is not better than Mozilla 1.0.

Re:Problems in Mozilla and Konqueror pre-3.1

[los furtive]

I've had the same impression with Mozilla 1.1, didn't take me long to go back to 1.0. Then I got bitten with 1.2, fortunately they came out with 1.21 fast enough. By then I'd switched to Phoenix, and now as the Quebecois say, everything is t'zigidoo.

XSL

[Captain Large Face]

Having CSS functionality in XML is a Good Thing, but would it not be worth waiting for a full implementation of XSL functionality on the client side before embarking on a full-on application?

Server side?

[Komarosu]

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 :)

Re:Server side?

[Rick the Red]

it seems pritty stupid to start the "oh you need this browser to view this site" wars again.

"start...again"? Don't you mean "continue"?

Odd...

[Daleks]

I was always wondering about directly applying CSS to XML documents. I recently made an XHTML version of my resume with the data in XML, the structure in XSL, and the style in CSS. I then use xsltproc to generate the XHTML file before uploading it. The thing was a lot of the code just looked like:

<xsl:template select="foo">
<div class="foo">
<!-- etc -->
</div>
</xsl:template>

.foo {
/* etc */
}

This is obviously redundant and a waste. XML+CSS+Mozilla would cut out the middle-man, which is great, but the downside to this is few people will be able to vew these documents as IE is still dominant. Even my XHTML resume won't show up properly in IE6. It validaes under XHTML 1.0 Strict and the CSS validates as well. I give up.

Re:Odd...

[Anonymous Brave Guy]

I feel your pain about getting XML/XSLT things working. Alas, until recently, Moz didn't handle basics like xsl:number properly, and the suggested workaround was "don't use it". Um... no. That made Moz pretty much useless for any serious XML/XSLT work I was doing. Apparently, that particular gremlin was a well-known one, and should be fixed in Moz 1.2, though, so maybe things are coming around slowly but surely...

Re:Odd...

[vbweenie]

<xsl:template select="*">
<div class="{local-name()}">
<xsl:apply-templates/>
</div>
</xsl:template>

or some variant thereof (e.g. <xsl:template select="foo|bar|baz"> for just the tags you want to translate directly to divs) might save you some time...

XSLT?

[Spudley]

CSS along with your XML content to render the formatted content in the browser

Um, I thought that was what XSLT is supposed to do?

Re:XSLT?

[vbweenie]

One typical use of XSLT is as a translator between marked-up data (XML) exported from somewhere and a marked-up hypertext document (HTML) presenting that data or a subset of it for the web.

Neither the XML nor the HTML will necessarily contain any formatting information beyond HTML's fairly basic set of tags, so you might still need CSS to finesse the layout and appearance.

An alternative is to translate from XML via XSLT into XSL:FO, and from there into PDF (using Apache's FOP). This is a still-maturing technology, however, and it's a bit verbose for my liking - but you can say that about most of the X* family...

Re:Bah. Boring. What's NEEDED is this:

[Curien]

Umm... yeah. Can show me how serialize C structs in *any* portable data format easily? Serialization in C is non-trivial. Serialization in a portable format is *incredibly* non-trivial.

Re:Bah. Boring. What's NEEDED is this:

[Anonymous Coward]

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.

While you might not be able to use .NET for your needs, checking out how the serialization works might help you to write your own routines.

Hope that helps...

Re:Bah. Boring. What's NEEDED is this:

[Curien]

Yeah, that's all well and good when you're writing managed code. Data structures in managed code have all sorts of nifty bits of meta-information floating about.

Now back to my point that serializing C structs is non-trivial.

Re:Bah. Boring. What's NEEDED is this:

[vbweenie]

You would have to parse the source files to get reflection. Wouldn't you?

A code-generation utility to write a FOO-serializing function for a struct FOO (given the source files where FOO and all sub-structs referenced in FOO were declared) might be worth having - a little bit like the proxy-generating utility I gather .net has for building classes out of WSDL files.

Re:Bah. Boring. What's NEEDED is this:

[Felipe Hoffa]

Maybe gSOAP is the answer for your needs.

It is a library for C and C++ that generates codes for using (as a client) or providing (as a service) web services using the SOAP standard (based on XML).

If you give gSOAP a header file with the methods and structures of your code, it will generate all the needed methods and XML descriptors without giving you much trouble. From there it will be easy to serialize all your data in and out, and you won't have to care about the details of the XMLs. As an added benefit you will be able to share your data with software written in several other languages.

Fh