• Reported by liorean

Well, in a break from my tradition of posting browser news, I'll turn to the topic of the various syndication formats; web applications; XML based formats in general; where the world is heading; and flying pigs. Well, not so many flying pigs, really, though I can point you to p0nju - PiggyHunter! if you want to read more on that topic.

XML ≠ Web syndication

Well, I guess anyone reading Webgraphics is also reading mezzoblue, but in any way, I'll refer you to the What is RSS/XML/Atom/Syndication? post Dave wrote recently. What I want to bring to your attention is the fact that the image most often used to link the feed is labelled "XML", not "RDF", "RSS", "RSS2", "Atom" or anything else, and that RSS is not a homogenous format which makes it even worse. The problem here is one of degree of complexity - XML is a general syntax for a structure, RDF is also a generic grammar and syntax, while all the syndication formats are vocabularies for the syntaces of XML/RDF. It's a clear mistake to associate the term XML with syndication feeds, because XML is so much wider than that in terms of areas of application. An example of why this is a mistake is a recent test I did, sending XHTML as 'text/html', 'application/xhtml+xml', 'text/xml' and 'application/xml', and testing XHTML support, whether browsers support xml-stylesheet PI, whether scripts are loaded, and whether DOM added scripts were executed and styles were applied. OmniWeb 5.0 beta 2 managed to do all of those things, surprisingly since Safari doesn't execute scripts added using the DOM. However, recent OmniWeb 5.0 betas have added web syndication to it's set of features, and now all XML is treated as were it a feed, effectively destroying your possibilities of using XML for anything else than syndication.

Syndication formats

There are numerous syndication formats - RSS being the most common, though it's split up over numerous versions. Atom and it's earlier cousins also have a large representation on the web. Named formats are XML based, and rather verbose. ESF is another, very slim syndication format, being raw text based. These formats, and one other, are the ones I will discuss here.

As I see it, a feed is supposed to contain a minimum amount of content. It should contain relevant entries since last update, whether as links to the full entries or having the full text contained. It should contain a datetime stamp for each entry within. It should contain the entry title. It should contain feed title, contact and link. If it provides the full entries it should contain author data. Presentation should be up to the client.

What I on the other hand don't want to see in a feed is data that is neither the entry contents, entry metadata, nor feed metadata. That means excessively verbose XML and data sent at XHTML. That means xml-stylesheet PI.

Of mentioned formats, ESF is the one that comes closest to meeting those goals. So close, in fact, that I would say it's single bad point is that it is limited to sending the entry addresses only. Well, many will disagree with me about this, but if you want more than that, you have a format that is explicitly made for it - (X)HTML. And that's where I, not for the last time today, turn to Ian Hickson. On his site you can find, among other goodies, a working draft for another syndication format based on XHTML, cowritten with Tantek Çelik. This format, HSL (HTML Syndication Format), provides any features from HTML that you might want to add to your feed. It uses XHTML elements and attributes to signify a feed that may be embedded inside any XML document. It allows for XHTML contents and the same facilities for styling. This format is what you want if you need your feeds to be nicely rendered in browsers. Atom or RSS is what you want if you want to send entry contents with the entry, but don't need XHTML contents. ESF is what you want if you are just going to link to the entry. That is my view on it.

Web applications

I've said before that the web will not be a battlefield for Microsoft or others for some time. Well, I'll repeat that again. However, web applications relate to user interface and not to documents, which is what distinction I make between the web and web applications. And as I make that distinction, I say with confidence that XAML, XUL, Java, Flash, PDF or even SVG will make no larger difference on the web until Mac OS 9 and Windows versions before Longhorn are largely phased out. Sure, the browsers and plugin manufacturers will try. Internet Explorer is our roadblock. As long as versions 6 and below are in any kind of majority, we will see the web stay like it is. There!

However, the web applications scene is in for a shaky future. If the wrong decisions are made, we will see a proprietary Microsoft controlled technology, whether open or closed, emerge as a de facto standard for web applications even though we have agreed on a single champion against it. Why? Because, while Internet Explorer is not necessarily as major a factor here, it will be what most people use to access web applications.

Web applications are of course lifted to the surface as the W3C are holding a workshop on it in a week, and the position papers that are available. Note especially the joint position of Mozilla and Opera, and the non-surprising positions of Microsoft, Adobe, IBM and the companies working with mobile phones and/or PDAs. Also note that Macromedia is absent.

I can see a trend here - all these heavyweight companies seems to leverage the technology they are working with/on and have spent millions of R&D money on, but none of them take the single most important factor into count - the user. Users live on Windows. Users use current versions of Internet Explorer, and will still do so for years from now. Windows Longhorn might be fitted with a new version of Trident (the rendering engine from Internet Explorer for Windows), but those glimpses we have seen have not contained one such. And even if Longhorn does bring us a new browser, how long will it take until that browser is mainstream? No, the single component of Longhorn relevant to this discussion is Avalon. XAML and the Microsoft Infopath are the future directions taken by Microsoft. Those are the technologies that will reign the web applications world if we remain at status quo.

What opposition do we have, then? Well, prominent among the technologies are SVG and XForms. PDF, Java and Flash are possibilities for proprietary opposition. And then we have Opera and Mozillas sole positions, of course. Of these technologies, in my opinion, the proprietary are worth a glance but nothing more. Java has fallen out of grace, and not even Sun are promoting it as a possibility. Macromedias position we know nothing of, but I would not be surprised if they would promote Flash. Adobe positions themselves with SVG and not PDF, of course. However, SVG is not the ideal solution. The SVG WG seems to never looks at the works of others, and the standards they develop are not interoperable on the level that XML should be. XForms on the other hand is better when it comes to interoperability, but lacks support and already competes with two similar technologies, notably one I've already mentioned, Microsoft Infopath. And it's overly complicated. Looking again at Hixies website, we can find a much more appealing specification to base it on in Web Forms 2, an extension of the HTML Forms system.

Well, only the Mozilla and Opera position left, then. Their position is clear: Backwards compatibility is of the essence. No plug-in should be needed for current Internet Explorer versions to support it. It should be based on HTML/XHTML, ECMAScript and the DOM. The technologies are already device independent and should not need profiling. Again, Hixie provides an entry on the issues and links to a document of David Barons on the fragmentation of the web. I don't believe this standpoint will win out in the W3C, but I believe it is the one standpoint that could effectively give the W3C control of the future web applications, instead of building a technology that does not work on current Microsoft software, and thus allowing Microsoft to roll their own de facto standard.

My belief is that SVG will win out as base technology here. The browser developers are guarding their rear and implementing SVG already, but requiring a plug-in like Adobe's SVG Viewer is not enough for getting to the Internet Explorer based audience. It's not backward compatibility per se that is needed - it's native Internet Explorer compatibility. And SVG does not provide that.

Finally, I want to again point to something you can find on Hixie's website - Web Applications Markup Language. I'm not sure that the browser vendors will go with the W3C approved technology on this - they don't want to lose this war. Better than to lose to Microsoft because of a bad decision on W3Cs part, they may chose to leverage a technology that will work in both their browsers and in Internet Explorer, if you add some HTCs to augment it's behavior. This technology may be it. And that's all the speculation in this area that I'm willing to do today...

XML based formats

I don't know if it's only me, but I see a clear overuse of XML formats. XML is a good format for creating hierarchical stuctures. It's benefits are that it has a strict requirement on the syntax of the document, that it allows XML based formats to be extended with new attributes and elements in new versions without being backwards incompatible, that it can mix with other XML languages in other namespaces, that it has native association of style sheets, links and non-parsed data (through CDATA blocks), that it can use a single parser for many different languages. It's drawbacks are that it is overly verbose, lacks error recovery, doesn't allow parsable HTML content (unless given content is XML well-formed), contains lots of redundant code, and requires a heavier parser than really necessary for most formats.

Thus, when people want fuzzy XML parsing (that is, they want error recovery) because their format would benefit from fuzzy parsing, my answer is that the strict well-formedness constraints are part of what makes XML XML. If you want to get rid of the well-formedness constraints you should instead turn your head towards another base syntax, XML does not allow what you wish for. (Involed people all know who I mean and which language I happen to be thinking of.) Also, as can be seen with the syndication formats, ESF is really much slimmer than it's equivalent XML format would be. CSS is much slimmer than it's XML equivalent would be. JavaScript is much slimmer than it's XML equivalent would be. Of those languages, JavaScript is probably the one that matches XML most in similarity of syntactical concepts, especially with it's hierarchical object model and it's variable structure - and though XML can be used to describe JavaScript, it's far from optimal, because the language is not used in a way that benefits from XML parsing and handling. The more syntactically limited, linear serial structure model of CSS or EFS would fit XML even worse.

In fact, with the exception of data appearing in a highly variable structure when that data is handled as data and not further processed, XML is seldom a good base format choice. YAML or JSON are more program close for most processing languages, require a far smaller and slimmer parser, and are often more easily readable. A plain text based format such as ESF requires a custom parser, but that parser is still more effective than using a pre-written XML parser for a format with the same purpose would be. No, such languages are not what XML is made for.

Well, enough negativity. XML is a great format when used right. It's easier to read than most other hierarchal languages, especially when deeply nested. It's verbose and consistent, so it makes understanding nested hierarchical structures easier than what it might be in other languages. It's unambigious and strict, which makes catching structure errors easier. It has the possibility of validating, to ensure that your document means what you believe it means. It's easy for human reading, and not that bad for human writing.