<xml.lt>

You may have noticed, and I have for sure, that submissions from our blog to Digg no longer work. We haven't changed anything on our side, and the URL-encoding in submission parameters was double-checked ant seems perfectly correct. What is most interesting though, that none of our URLs work even when you submit them "by hand" at Digg - Submit Item, no matter that they are perfectly correct and accessible.

Unlikely as it may seem, but I can't help but think that this is a bug on Digg's side. And the only explanation for this behavior I can think of, is that Digg for some reason converts submitted URLs to lower-case before processing them. That doesn't work since our URLs are upper-case and case-sensitive. This kind of behavior would be obviously incorrect, since the path element of an URI is case-sensitive.

Any ideas on this matter?

Using XML as data serialization and XSLT as a templating engine (which DIY Framework does by default), it is pretty trivial to localize your Views for multiple languages.
Simply create an XML file (either one for each specific View or a general one for all the Views) and place it where your XSLT stylesheets can access it. It will contain localized phrases. Each phrase will have a unique identifier and a string value in each of the languages you use. XML has a special reserved attribute xml:lang for identifying the language of the content using language tags. For example:

<phrases>
	<phrase id="insulation">
		<text xml:lang="lt">Izoliacija</text>
		<text xml:lang="en">Insulation</text>
	</phrase>
	<phrase id="mufflers">
		<text xml:lang="lt">Slopintuvai</text>
		<text xml:lang="en">Mufflers</text>
	</phrase>
</phrases>

Then you can access these phrases in your XSLT stylesheet using the filename, phrase ID and a special XPath lang() function:

<xsl:value-of select="document('../phrases.xml')/phrases/phrase[@id = 'insulation']/text[lang($lang)]"/>

Here $lang is the code of the language we want to display our View in. It was defined as a parameter of the stylesheet. In that way we select the localized version of the phrase.
How to retrieve the language code (which will be passed as the value of $lang) is a matter of application design. Probably the simplest solution is to specify a request parameter containing a language code on the Resources you want to localize, e. g. Products/?lang=en. You can also implement an automatic language selection using HTTP content negotiation with the Accept-Language header.

Google has recently announced formation of Open Handset Alliance and development of an open mobile phone platform, called Android. It is rumored to be the platform for GPhone.

A preview version of the SDK will be available to developers on November 12th.

It would be interesting to see how Android compares with other mobile platforms such as Symbian and Embedded Linux. Anyhow, these are exciting times for the smartphone industry as well as software developers.

During the last months, a wave of new exciting Semantic Web applications started to appear on the Web:

Twine

A new service that intelligently helps you share, organize and find information with people you trust. Introduction screencast.

Powerset

Natural language search.

True Knowledge

Direct answers to human and machine questions. Introduction screencast.

Freebase

An open, shared database of the world's knowledge. Introduction screencast.

Several of their creators talk in the Web 2.0 Summit - The Semantic Edge presentation.
Most of these applications are so far stealth or invitation-only. It also remains unknown whether they use W3C technologies such as RDF, OWL, or SPARQL. However, this seems like a powerful trend of Semantic Web actually taking off.

Relational databases have been around for decades. They are the most popular and successful form of databases. Also now on the Web, although the concept was created long before the Web emerged.

We feel however that relational model does not fit the Web in several ways, and that application design and implementation using it is not as easy as it should be.

Naming of resources on the Web is hierarchical: domain system, file paths, and URIs all have a common tree structure. On the other hand, the Web is a network from the very core: physical computers, links between Web pages, P2P agents etc. all form giant graphs.

What is more, the content on the Web is very heterogeneous and often semi-structured. There is data-oriented and document-oriented content, and one should be able to mash it together easily and dynamically. That is where XML (also tree-structured) is used and succeeds.

Now, relational model is not good neither at representing tree structures nor graphs, which basically means it is not good at representing the most important structures of the Web. That requires applications to convert between data models before content can be published on the Web, which is time consuming, error-prone, and puts a penalty on performance. Relational schema is very inflexible and virtually cannot be changed on the fly. Have you ever seen a Web application executing ALTER TABLE statements? The instance data cannot be used without a schema, they are tied together, unlike in XML or RDF. For more or less the same reasons, relational databases are not easily decentralized or integrated back together, especially at run-time.

Relational model has already bent over to accommodate XML and RDF, but it should move even more further aside. Semi-structured data in the forms of XML and RDF will further prevail. As will do programming languages such as XQuery that allow coding the whole application without ever leaving the same XML data model.

Researchers at MIT also predict that it is The End of an Architectural Era (It’s Time for a Complete Rewrite).