Mozilla + CSS + XML = Structured, Formatted Content 28
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."
*ahem* (Score:3, Funny)
Re:*ahem* (Score:5, Insightful)
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 (Score:2)
Moving processing from servers to clients? (Score:3, Funny)
Re:Moving processing from servers to clients? (Score:1, Informative)
Even in Opera 7,.. IE (5) has some problems,..
Re:Moving processing from servers to clients? (Score:2, Informative)
Re:Moving processing from servers to clients? (Score:2, Insightful)
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: (Score:1)
Here's the caveat: Easily.
Surely someones' got some tools for taking C code-style structs and turning them into an
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
Re:Bah. Boring. What's NEEDED is this: (Score:2)
Re:Bah. Boring. What's NEEDED is this: (Score:1, Insightful)
While you might not be able to use
Hope that helps...
Re:Bah. Boring. What's NEEDED is this: (Score:2)
Now back to my point that serializing C structs is non-trivial.
Re:Bah. Boring. What's NEEDED is this: (Score:1)
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: (Score:4, Informative)
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
Problems in Mozilla and Konqueror pre-3.1 (Score:3, Insightful)
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>
^
Re:Problems in Mozilla and Konqueror pre-3.1 (Score:1)
Re:Problems in Mozilla and Konqueror pre-3.1 (Score:1)
On reading the article a bit closer:
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 (Score:1)
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 (Score:1)
Re:Problems in Mozilla and Konqueror pre-3.1 (Score:2)
Re:Problems in Mozilla and Konqueror pre-3.1 (Score:1)
XSL (Score:2)
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? (Score:2, Insightful)
Re:Server side? (Score:2)
Odd... (Score:1)
Re:Odd... (Score:2)
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... (Score:1)
<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? (Score:1, Redundant)
Um, I thought that was what XSLT is supposed to do?
Re:XSLT? (Score:4, Informative)
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...