w3future.com

Site Search
Site Colors
Site E-mail Me

Syn Atom 1.0
Syn RSS 0.91
Syn Subscribe

CC Licensed
Geo URL
With Radio

On Resources

Tim Bray has posted his view on resources. He asks in what way the TAG should deal with them. He gives two unsatifactory options: either don't mention them at all, or say that the nature of resources is outside of the scope of the Architecture document. Here's my take on this.

First we should collect minimal requirements about resources and URIs, the axioms of the web. Let's start with this one:

• A URI identifies a resource.

It's a simple axiom, but actually very powerful. For example, this means that every resource for which a URI exists has an infinite life span: A URI is a string, and a string has an infinite life span. (Just like any number will always exist) As each URI maps to a resource, the resource must have an infinite life span too. This means f.e. that HTTP's 410 GONE means that there are no more representations available for the resource, not that the resource doesn't exist anymore. This is all the result of this one axiom. Let's do another axiom:

• Information about the nature of a resource that has a URI can only either be obtained by dereferencing its URI or simply declared to be true.

You can not for example look at the content of the URI for more information. Also, each time a URI is dereferenced, more information about the resource is known. But as a resource has an infinite life span, we can never know everything about the resource. So because we can never know the exact nature of a resource, it is enough to define it as everything there is to know about that resource:

• A resource is the collection of all results of all possible dereferencing methods at any time of its URI combined with all that is simply declared to be true about that resource.

If we don't like this conclusion then we should choose other axioms.

(It's very late, and it is very well possible that my logic is flawed. It certainly isn't solid enough to be called a proof.)

A stable RSS

At some point, I hope RSS stabilizes, people stop fighting over it, and just let it be. It's very useful, really very simple, and it belongs to users, not techies. It's unique in that regard, most XML specs are incomprehensible to people who use the stuff. RSS is quite comprehensible, by design. [Dave Winer]

I'm not really following the software industry long enough to say, but it seems to me that every format either evolves or becomes obsolete. Am I wrong here? If I'm not, is there something different about RSS that this rule doesn't apply?

Update: After getting some feedback I realized I meant superseded, not obsolete.

Xopus response

Working on Xopus is really fun and challenging, but when you read this then you know that's really why you don't mind working long hours.

New SVG 1.2 Public Draft

Antoine Quint announced the release of a new SVG draft. Rendering Custom Content (RCC) is great. I'm looking forward to the examples. I want an SVG only version of my site, but it has to be a quick, easy and elegant job to do. Some server side XSLT, frameworking the layout with RCC and styling with CSS sounds attractive.

You just have to know where to look

Note to self: If something bugs you in Radio Userland, it is usually very easy to fix. The shortcuts weren't expanded in the RSS feed, so I posted a message on de discussion board. Steve Hooker was a great help, and in the meantime I learnt to fix something else that had even annoyed me more the last few years: activeURLs and autoParagraphs. It turns out that it is enough to add this to #prefs.txt:

#activeURLs false
#autoParagraphs false

Echo feed available

Yesterday Dave Winer added support for Echo to Radio Userland's aggregator. Today I did the same, but at the other end. My Radio Userland now emits an Echo feed. The RSS feed is now created by transforming the Echo feed, using this XSLT transformation.

Q42 is hiring

If you like what Q42 is doing, then now is the chance to join us. Q42 biedt een uitdaging aan. (You need to be able to read Dutch).

That's my brother!

No, that wasn't a typo. My brother did indeed walk 80km, in one stretch. From here again congratulations, Jelle! Some background information: Jelle participated in what is called the Kennedy March in Someren. He and 2444 others started at 10 o'clock in the evening. They walked straight through the night without sleep. Jelle finished more than 18 and a half hours later. A marvelous achievement!

My brother just walked 80km!

Programming vs. XML

The API discussions during the last week showed clearly that a lot of programmers are not ready for XML. They prefer XML-RPC because they want to send and receive data structures that are in native form for their programming language. Yet everybody seems to agree that when you are creating a new data format, it should use XML.

For this friction to disappear one of two things has to happen: Either the programming languages change to match XML better, or the other way around. The W3C XML Schema standard was an attempt to the latter, and it works great when you're working in a programming environment like Microsoft's .Net, because it tries to give XML an Object Oriented feel. But when you're working directly with XML, RelaxNG seems to be the better match. RelaxNG works a bit like regular expressions. This is not a coincidence, because regular expressions were designed for text processing, and that's where XML has its roots too.

In the end I think XML will win. The data structures in programming languages are designed to match the computer's memory model. XML's data structures are a result from it's syntax. Although this does lead to some peculiarities, it has some interesting properties that are more natural for the human's memory model. Compare the data model of a book with one author with the data model of a book with one ore more authors. In the human's memory model these are almost similar. In XML it is equally similar, you have either one or one or more author elements. In most programming languages the second suddenly needs an extra data structure: a list of authors.

As programming languages abstract away from the hardware, they'll probably keep getting better support for XML. But changing the actual data structures, and certainly lists, is a big step for a programming language. This will stay interesting to follow for years to come.

XML-RPC, SOAP APIs derived from a RESTful API

This is an idea I had, which I posted on the XML-RPC, SOAP, and/or REST discussion. Sam Ruby thinks this is a “real winner of an idea”, so I'll repeat it here:

I think we can use the general idea from the MetaWeblog API: apply a given set of rules to convert XML data to the XML-RPC model. The problem with the MetaWeblog API is that the XML data model isn't clear enough: If an element can occur more than once, the member in the struct has to contain an array. But it is not clear enough in RSS which items are allowed to occur more than once. Necho doesn't have this problem, because it has a schema.

It would be very easy to create an XSLT that converts a Necho document into an XML-RPC document. It would even be doable to create an XSLT that converts the Necho schema to a Necho-to-XML-RPC XSLT. I think I'll have a go at that, it's a fun challenge I think.

The bottomline: let's first create a RESTful API. The SOAP and XML-RPC APIs can then easily be derived from that.

Creating well-formed XHTML with IE or Mozilla

Sam, we are in violent agreement as to the value of well-formed and XPATH-searchable content, something I have recently sought to demonstrate. I think -- no, I am sure -- that you radically underestimate the distance between possession of a tool (IE or Mozilla) that can validate well-formedness, and ability to produce well-formed content in routine written communication.[Jon Udell]

At Q42 we deploy purpose-built CMSes with simple WYSIWYG in-browser editors on a regular basis. The editors are comparable to what blogging tools like Radio Userland are using (using the contentEditable attribute). We have a simple client-side clean-up script that extracts well-formed XHTML from the WYSIWYG editor. It even handles pasted HTML from Word rather well. I discussed it with my collegues today, and we are willing to make that script available as open source if people are interested. (We'll have to wrap it up nicely first, so it can be used easily by others.)

John Udell also talks about credible competition for Microsoft's InfoPath. That's nice timing, because we (Q42) are about to release the first commercial version of Xopus, the friendly XML editor. There's a nicely designed new homepage, not much there yet, but 2 nice screenshots. You can ask for a beta trial version.