<xml.lt>

Might be old news, but still it's nice to see that Microsoft is working on the Internet Explorer browser and has announced in its development blog that IE8 passes the Acid2 test. A first public beta is planned in the first half of 2008.

Acid2 is a test page, written to help browser vendors ensure proper support for web standards in their products. So far Safari, Opera, and Konqueror (as well as some other browsers based on their platforms) are listed as compliant with the test.

If you're using XSLT to build web pages, you should have come across situations where you need to build a query string from parameter or node values to make a (X)HTML anchor link. Sounds trivial enough, but more logic gets involved if one or more parameters are optional — you have at least to take care of trailing apostrophes. Since that involves <xsl:if> or other control elements, the logic does not fit nicely within the attribute value template { }, which is a very handy XSLT construct (basically a shorthand of <xsl:value-of> for use in attributes).

The solution we use, is to have a separate named template for building the query string. You pass the values you need to appear in the query string as template parameters, and get the whole string back:

<xsl:template name="query-string">
	<xsl:param name="lang-param"/>
	<xsl:param name="view-param"/>
	<xsl:param name="offset-param"/>
	<xsl:param name="limit-param"/>
	<xsl:param name="order-by-param"/>

	<xsl:variable name="temp-qs">
		<xsl:if test="$lang-param != $default-lang">lang=<xsl:value-of select="$lang-param"/>&amp;</xsl:if>
		<xsl:if test="$view-param">view=<xsl:value-of select="$view-param"/>&amp;</xsl:if>
		<xsl:if test="$offset-param">offset=<xsl:value-of select="$offset-param"/>&amp;</xsl:if>
		<xsl:if test="$limit-param">limit=<xsl:value-of select="$limit-param"/>&amp;</xsl:if>
		<xsl:if test="$order-by-param">order-by=<xsl:value-of select="$order-by-param"/>&amp;</xsl:if>
	</xsl:variable>
	<xsl:if test="string-length($temp-qs) &gt; 1">?<xsl:value-of select="substring($temp-qs, 1, string-length($temp-qs) - 1)"/></xsl:if>
</xsl:template>

You can assign the query string to a variable before constructing the link, and still use the attribute value template:

<xsl:variable name="query-string">
	<xsl:call-template name="query-string">
		<xsl:with-param name="lang-param" select="$lang"/>
		<xsl:with-param name="view-param" select="'all'"/>
		<xsl:with-param name="order-by-param" select="'Event.CreationDateTime'"/>
	</xsl:call-template>
</xsl:variable>
<a href="{$resource/*/@uri}{$query-string}">Recently added</a>

Another possibility is to pass the query parameters and values in a single nodeset instead of several template parameters.

DBpedia is a community effort to extract structured information from Wikipedia and to make this information available on the Web. It is a fine example of the next generation semantic applications and can be compared by functionality to Freebase which also uses Wikipedia's dataset. The difference is that DBpedia's data and framework are open-source, and it is built using W3C standards such as RDF/OWL and SPARQL.

DBpedia makes it possible to ask sophisticated queries, such as as to select “people influenced by Friedrich Nietzsche” or “German musicians who were born in Berlin”. The second query looks like this in SPARQL (prefixes omitted):

SELECT ?name ?birth ?description ?person WHERE {
     ?person dbpedia2:birthPlace <http://dbpedia.org/resource/Berlin> .
     ?person skos:subject <http://dbpedia.org/resource/Category:German_musicians> .
     ?person dbpedia2:birth ?birth .
     ?person foaf:name ?name .
     ?person rdfs:comment ?description .
     FILTER (LANG(?description) = 'en') .
}
ORDER BY ?name

It can be executed using one of the several SPARQL endpoints (see results here).

The datasets, now containing 103 million triples that describe 1.95 million things, are published online as linked data and can be browsed using semantic browsers such as Tabulator. They are also available for download.
What is even more exciting, DBpedia is also being linked to different other semantic datasets such as MusicBrainz (information about music and artists) and GeoNames (information about geographical features), becoming the core of W3C's Linking Open Data project.

For those who missed it, SPARQL Query Language for RDF became a W3C recommendation on January 15th.

OdinJobs published an interview with some PHP folks on why they think PHP rocks. I was glad to contribute a little :)

W3C has published the first working draft of HTML 5. In it, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability. However, at the same time there is ongoing work on XHTML 2.

How do these specifications relate to each other? HTML 5 claims that XHTML 2 only fits the document-oriented paradigm, but there is a need to extend the HTML vocabulary to support non-document content such as forum sites and online shops. They come in different namespaces, so there should be no conflict in that.
XHTML 2 should further increase semantics and separation between content and presentation, move to a modular approach in combination with XForms, and base on XML. HTML 5 on the other hand tries to incorporate features used in practice.
XHTML 2 seems to be pushed by the W3C, while HTML 5 is backed by vendors such as Mozilla and Opera, which started the work on it in WHATWG but eventually joined W3C's HTML working group.

To make things even more confusing, HTML 5 draft proposes 2 authoring formats: one based on XML (called XHTML 5), and one based on a custom format inspired by SGML (called HTML 5). Vendors are encouraged to implement both.

So far the future of the relationship seems very unclear, as both HTML 5 and XHTML 2 seem to compete in trying to replace HTML 4 and XHTML 1. It would be hard to imagine future versions of HTML not based on XML. Anyway, if this is about to become a standards war, which is the very least thing needed on the Web today, the real losers will be users and developers.

More insights in X/HTML 5 Versus XHTML 2 by XHTML.com and HTML V5 and XHTML V2 by IBM developerWorks.

Recently, a number of initiatives complaining about Web applications being built as walled gardens and not allowing users to control their data or transfer it across to another application started showing up, especially in the social networks area: Data Portability, Open Social Web, OpenID. They demand ownership and control over profiles and relationships, and publishing of them using open standards.

Although many Web 2.0 websites started offering APIs, they do not solve the problem completely. Most of them are based on XML, which is machine-readable to great advantage, but still leads to the N^2 problem — in order to be integrated, each pair of applications has to be programed accordingly, with the knowledge of API and formats on the other end.

The true solution here might also become a bootstrap for the Semantic Web, which is not about some kind of Artificial Intelligence right now, but about data integration in the first place. In fact, the Web 2.0 data portability initiatives resemble the semantic Linking Open Data community project a lot. To support true data portability, Web applications should publish their data as RDF Linked Data, and ultimately provide SPARQL query endpoints and employ OWL ontologies.

We've been recently thinking about how to implement a cache over the DIY Framework. Ideally it should be an extra layer in the application and not require making changes in the underlying design.

The golden rule of caching says, that it is best to cache as close to the final product as possible. It is good to cache a result set, but best best to cache the whole webpage. So we'll focus on that, since it is also easier to implement as a separate layer.

Imagine a product webpage. There a couple of forms on it (e. g. for comments), and the page is only updated when they are submitted. Otherwise the content stays the same, so it can be cached and served until the page is updated again. The important thing is to know when the update happens and when to invalidate the cache.
Unfortunately (or not), there are web pages that are not updated directly via HTTP methods. They change because other pages get updated. Imagine a list of most recent product comments. It would take some logic to figure out when it was updated — at least retrieving the timestamp for the most recent comment. It makes cache invalidation hard.

The benefit of REST architecture and our framework is that resources are fine-grained. If there is a resource with a URI Products/123 and it received a POST (or basically any non-GET) request, we can assume it was updated. It would be harder to figure out in a non-RESTful design, for example if all the product requests would be handled by a single script and URIs would be something like products.php?id=123.
Making all forms submit to the same URI as they are served on seems also to be a good practice. If a product comment would be submitted to some comment.php instead, the cache would not know that the product page was updated.

Now we need to figure out how to implement this using some memory cache (such as eAccelerator) and sending correct Last-Modified and Cache-Control headers :)

Whenever I need to use complex GUIs that are supposed to hide the complexities of the code or generate it for you as a convenience, or complex configuration files, I get the feeling that something is not right, that they actually stand in the way of doing my work rather than helping me.

One example could be ASP.NET in Visual Studio and that kind of interfaces. A few clicks in a wizard allows you to bind the database and show a table of data on your page. You can of course add or remove columns, change styles and appearance etc. But since you do not actually control the code behind it, and if you are doing something more advanced, you hit the wall eventually since there is just no way to do it using the interface. Then you still need go down to hack the code. And in the meanwhile you have been learning all these knobs and buttons of a proprietary program instead of using and extending your knowledge of SQL or HTML.

Another example I can think of is huge declarative configuration files, usually written in XML. They are common in Web frameworks such as Struts, but probably elsewhere, too. They were probably built to make things simpler and just hold some constants, but then got out of hand and blew up. At some point it might seem that you are configuring more than coding, and still are not able to achieve what you want. And again, to do that you probably had to figure out a whole specification of a custom XML schema that you will not be able to use somewhere else, instead of sticking to your plain old Java code.

I am not saying customizable interfaces and configuration files are useless, but I think this rule applies:

At some point, customizable tools which are meant to ease the software development become so complex that it takes more effort to figure them out and customize them for your needs rather than build what you want from scratch.

The RESTful Web Services book provides three basic rules for URI design, born of collective experience:

1. Use path variables to encode hierarchy: /parent/child
2. Put punctuation characters in path variables to avoid implying hierarchy where none exists: /parent/child1;child2
3. Use query variables to imply inputs into an algorithm, for example: /search?q=jellyfish&start=20

We have come up with very much the same principles in our designs. The second rule however seems to be rarely used in practice.

The rules are tested and precise enough, but it is the definitions used in them that are not always clear. What constitutes a hierarchy? A strict class/subclass/instance tree is probably the most logical and intuitive form of it, for example Places/Clubs/VEGA. It should be used whenever it applies, but that is not always the case. Another good example is things that are embedded one into another, such as Countries/USA/Georgia/Atlanta.

Many hierarchical paths however break these two patterns, or mix them. For example, Places/Clubs/VEGA/Pictures/ or user/john/tags/ do not represent a strict hierarchy. Pictures/ is neither an instance of Places/Clubs/VEGA/ nor embedded in it in a strict sence. Still it is a kind of resource that should be given a RESTful URI.

Imagine that we would like to add pictures for every location in our location hierarchy. The pictures of USA would then be addressed as Countries/USA/Pictures/. This breaks our URI “embeddedness” hierarchy by adding some “metadata leaf nodes”, which are not true nodes (locations). When handling such a request most Web applications (especially those based on URL rewriting) would not be able to easily tell that Pictures/ does not refer to one of the US states as Georgia/ does. Last.fm for example distinguishes between these two kind of URIs by using a + prefix: music/Radiohead/In+Rainbows (album) vs. music/Radiohead/+events. Using the DIY Framework that is not necessary, since each resource has an explicit type which does not depend on its URI.

Another example found in practice is path URIs used for pagination, e. g. user/john/tags/all or /posts/4/pages/2. Again, they break the strict hierarchy, but also lead to the definition of algorithm in the 3rd rule. In our eyes, pagination is much more an algorithm than a kind of hierarchy. One can argue philosophically about resources and how best to design them, but we see a list of posts as a single resource which representation can be paginated used query parameters passed to an algorithm rather than a number of resources for every page. It can also have more inputs than the page number, e. g. the number of posts per page or the sort order, which would be hard to embed in the path. Therefore we use pagination URIs like Products/?offset=1200&limit=20.

The bottom line is that the URI space is infinite, but in practice the design choices for logical RESTful URIs are often difficult and constrained.