So I filled out a form requesting to speak. To my surprise, the Chair invited me to testify early in the hearing.

Before I spoke, however, a representative from the Mayor's Office voiced opposition to some specifics of the proposal. Earlier that day, at the Personal Democracy Forum elsewhere in the city, the Mayor himself announced several initiatives regarding publishing government data. This had generated some excitement, and a number of people who had been attending the conference (I had not) were present at the hearing.

The Mayor's Office cited 5 or 6 reasons why it opposed the particular proposal (which I trust will appear in the public record that I've not yet located) but the main ones I recall were cost and burden. I would paraphrase some of the exchange between the city council committee and the Mayor's office as follows:

• City Council: Please put raw data on the Web.
• Mayor's Office: We prefer publishing information that is less raw and more citizen-friendly.
• City Council: Citizens won't know what they are missing unless you put it up there.
• Mayor's Office: That will cost too much (e.g., scanning old documents). We have lots and lots of documents.
• City Council: By choosing what to provide and massaging the data, you are not letting people make better use of it.
• Mayor's Office: See the initiatives we just announced. We think that we are meeting customer needs (which we hear through surveys, complaints, etc.)
• City Council: You shouldn't decide what people want. Let them decide.

W3C's eGovernment Interest Group has been working with a growing number of agencies to gather information that will help address these sorts of concerns. Now they will develop best practices and guidelines for publishing government data. This is not an area I know well, so I look forward to being able to refer to the eGov IG's findings. However, I'm sure New York City is not the first government to wrestle with the technology, the cultural issues ("why should I publish my data?"), and how to use taxpayer money to do this.

When my turn came to speak, I said something like this:

• Thanks for using open standards.
• Use W3C Semantic Web Standards to publish data. As a starting point, I referred to Tim Berners-Lee's recent draft of Putting Government Data online
• Don't try to do everything at once. Start with what is already available electronically, for example.
• Don't require agencies to coordinate through a single portal. Let them publish data at their own speed. Then aggregate (through a single portal if you wish and if people find that easy to use).
• Participate in the eGovernment Interest Group.

I hope my summary here is backed up by the public record.

One strong feeling I had while in San Jose, was a sense of /deja vu/ in the Web world. Stepping back, I realize that 2009 feels a lot like 1999 when I was consulting with Allaire (remember CFML and ColdFusion?) and attended their user group meetings teaming with enthusiastic Web developers with war stories about their successes and failures bringing Web development servers into organizations of all types and sizes.

Ten years ago, many enterprises were just getting onto the "e-commerce bus," having been either eclipsed or inspired by the likes of innovative Web-centric companies such as Amazon.com and eBay who launched in 1995, or early-adopter retailers like JCPenney whose understanding of the catalogue business put them online faster than many other retailers, or businesses for that matter. Many mainline companies were in various phases of their Web evolution in 1999 -- from brochureware to intranets to pilot customer-facing interactive sites. And keep in mind that ten years ago, Google was barely two.

In 1999 there was also a wide cross-section of skill sets and diversity of understanding about what the Web was, how it worked, and what people and tools to trust to bring one's vision onto the Web. I remember sitting in focus groups with a number of HTML Web designers who were impatient with their more senior corporate IT colleagues who insisted on clear roadmaps, risk assessments and cost-benefit analyses for the Web-based tools and technology solutions their companies were considering.

The Java developers, engineers and system architects in other discussion groups also weren't too keen on the irreverent attitudes and huge amounts of money being thrown at these young people, who just a few years earlier were teenagers playing video games at the arcades. But understanding and trust continued to build, innovation accelerated, communities with technical skills increased, and revenues skyrocketed as a direct result of vendors developing and companies embracing new Web technologies.

We fast forward to 2009 and see similar dynamics with Semantic Web technologies. There are the early adopters and evangelists who have already climbed aboard the "RDF-bus," understand what's possible with W3C's Semantic Web technology standards, and can point to impressive results in new tools, pilot projects and even robust deployments within organizations, governments, and enterprises.

Yet skeptics remain both in terms of understanding the paradigm shift that the Semantic Web brings, just as the early Web challenged the status quo, and in the legitimate need for better tools and long-term architectural considerations for how to successfully deploy Semantic Web technologies in large enterprises.

Like the early Web and the W3C standards and subsequent commercial tools, products and services that enabled its rapid growth, the W3C Semantic Web stack is highly stable today. The accelerating uptake of W3C Semantic Web standards, new tools and applications were part of the buzz at this year's Semantic Technologies Conference.

In addition to hearing and seeing many new use cases and case studies, the call for commercialization was clear, as was the amount of enthusiasm among the technologists doing good and exciting work. The community's call to publish and link data in RDF or RDFa is clearly being heard, with The New York Times joining the ranks of large data holders eager and willing to publish to the Linked Open Data Cloud.

Finally, the number of Semantic Web communities flourishing in cities coast to coast across North America and in Europe, is another healthy sign that the growth and adoption of Semantic Web technologies has not only "crossed the chasm" (in keeping with Geoffrey Moore's model), but has spawned strong beachheads of support among highly skilled technology professionals across business, industry, and government sectors.

It is my hope that at next year's Semantic Technologies Conference -- which is changing venues to San Francisco -- we will point to an even higher coordinate on the adoption curve and see amazing new results and impact from the use of W3C Semantic Web technologies. If I were Jean Luc Picard, I would, "Make it so." But for now, I'll continue in my role of education and outreach for W3C.... Look forward to seeing many of you throughout the year and at next year's conference!

Come to think of it, the majority of the human population is probably more comfortable in a language other than English. It happens to be that English is the working language of W3C (and most international organizations) but that does not mean that other languages are not equally welcome at W3C. In fact, W3C encourages volunteers to contribute their valuable time and effort to translation of W3C standards and other resources.

I'm particularly proud of the Policy for Authorized W3C Translations which allows the production of translations that are recognized by W3C. This is especially useful for W3C standards such as Web Content Accessibility Guidelines (WCAG) 2.0, which are read and used by a large number of people. Besides Web developers, WCAG 2.0 is also used by decision makers, researchers, accessibility advocates, and people with disabilities from around the world.

Today the W3C Web Accessibility Initiative (WAI) announced the publication of the French Authorized Translation of WCAG 2.0. It is the first Authorized Translation of WCAG 2.0 and we expect others in Brazilian Portuguese, Catalan, Chinese, Czech, Danish, Dutch, German, Hindi, Hungarian, Italian, Japanese, Korean, Portuguese, Russian, Spanish, Swedish, and more to follow. There are also several unofficial translations available and in progress. The WCAG 2.0 Translations page lists completed and planned translations.

While this is an impressive list of translations, it is still only a small fraction of all existing languages. For instance, I am looking forward to being able to read WCAG 2.0 in Arabic. If we want to support the diversity of languages and cultures on the Web then we must continue to develop and promote such translations. Please engage and help us promote translations for W3C standards such as WCAG 2.0 in all languages of a truly World Wide Web.

I published a blog entry on right before my journey back to Europe (and an addendum because I forgot something in the original blog entry…) with much more details. If you are interested in more detailed impressions on the conference, you can read it there. Suffices it to say: it was a great week!

HTTP,HTML,URI

The general principle of platform design is that platforms consist of a set of standard interfaces. Standard interfaces allow substitution of components across the interface boundary, while independence of interfaces allow evolution of the interfaces themselves. In a PC, for example, the disk bus interface allows many different disk vendors to offer disk products independent of the model of display or keyboard, but the orthogonality of interfaces allow evolution of the interfaces themselves. If the display interface were linked to the disk interface too tightly, it wouldn't be possible to evolve ISA to SATA without updating VGA.

In the web platform, the three important interfaces are transport, format and reference, and the current definitions of those interfaces are HTTP, HTML and URI. The interfaces are standard, allowing many different implementations: HTTP standard lets you use HTTP servers from many vendors, the HTML standard lets you use many different HTML authoring tools or template systems, and the URI specification allows identification of many different components.

While HTTP is the current "common denominator"  protocol that all web agents are expected to speak, the web should continue to work if web content is delivered by other protocols -- FTP, shared file systems, email, instant messaging, and so forth.  HTTP as it has evolved has severe difficulties, and designing a Web that only works with HTTP as it is currently implemented and deployed would unfortunate. We should work harder to reduce the dependencies and isolate them.

HTML is the 'lingua franca', the common language that all agents are currently expected to be able to produce, process, read and interpret (or at least a well-defined subset of it). Having a common language is important for interoperability, but  the web should also work for other formats -- extensions to HTML  including scripting, DOM APIs, but also other formats and application environments such as XHTML, Java, PDF, Flash, Silverlight, XForms, 3D objects, SVG, other XML languages and so forth. Certainly HTML has it has evolved is overly complex for the purposes to which it is designed.

The URI is the fundamental element of reference, but the URI itself is evolving to deal with internationalization, reference to session state, IRIs, LEIRIs, HREFs and so forth. Many applications use URIs and IRIs, not just the formats described above but other protocols and locations, including databases, directories, messaging, archiving, peer-to-peer sharing and so forth.

The is just one of many communication applications on the global Internet; for web browsing to integrate will with the rest of the distributed networking, web components should be independent of the application, and work well with messaging, instant messaging,  news feeds, etc etc.

A sign of a breakdown of this architectural principle would be for a specification of a format (say HTML) to attempt to redefine, for its purposes, the protocol (say HTTP) or the method of reference (URI).  The specifications should be independent, or at least, dependencies isolated, minimized, reduced. If those other elements of the web architecture are incorrect, need to evolve to meet current practice or have flaws in their definitions, they need to evolve independently, so that orthogonality of the specifications and reusability of the components are the promoted.

There may well be reasons to link some features of HTML to the fact that it is delivered over an interactive protocol, but linking HTML directly to HTTP in a way that features would work only for HTTP and not for any other protocol with similar features – that would be unfortunate. It might not matter in the short-term (that’s all we have right now) but it is harmful to the long-term evolution of the web.

(Should go without saying, but just in case: this is a personal post, not reviewed by the TAG)

Michael writes:

Erik Naggum, dead? Is it possible? One person fewer who remembers the old days.

I never myself had any direct interactions with Erik, but I can say that it seems to me he did quite a lot to ensure that the old days would be remembered by those who came after. At least I can say that he helped me learn quite a lot about the history of the community and some of its important technologies -- because, at the time when I first learning about XML and SGML, I discovered in the SGML/XML Archive Sites section of Robin Cover's Cover Pages site a link to an SGML Repository at the University of Oslo Department of Informatics, with a note saying that the archive was "created and is supported by Erik Naggum."

Among the exhaustive range of resources there that can no longer be found anywhere else (including everything from PostScript sources for particular documents to complete archives of long-gone mailing lists), anybody with half an interest in SGML or even XML is likely to find something invaluable (in my case, one part that I'm particularly thankful for being able to find there were items related to the history and evolution of DocBook).

I never got around to contacting Erik to say thanks while he was still alive. So I hope this posting here can make up a little for my neglecting to have done that.

Erik, thanks.

I did notice however several mentions of the "HTML5 standard" that led me to write this post to remind the community of the current status of the specification, both in practice and on the standards track.. HTML5 isn't a W3C standard. We certainly look forward to the day when it is, but it isn't yet. In fact, the specification, co-authored by Ian Hickson from Google, is still very much a work in progress. We still don't have a required video codec to be supported by all browsers. Lively discussion is still happening in the HTML Working Group about the level of consensus around the spec. Sam Ruby of IBM and Chris Wilson of Microsoft are trying to move the Group forward. At the moment, HTML5 is only a working draft and Ian hopes to get it ready for Last Call review in October/November 2009 timeframe. Some of the work is also happening in the Geolocation, CSS and Web Applications Working Groups, so not all of it is under "HTML5".

So, while it is great to see support for and implementation of HTML 5, the community has not yet reached agreement enough to call it a standard, and it has not been implemented consistently across multiple browsers. Building a test suite will help a lot and we don't have one yet. This is an area that we intend to explore and to seek community support.

In some posts on the www-tag mailing list, I was trying to point out the risks in defining languages such that the "meaning" of the language depends on operational behavior. In some ways, of course, this is a fallacy: in general, what an utterance "means" in some operational way depends on what the speaker intends and how the listener will interpret the utterance.

However, as an organization, W3C can, and should, define languages in which the meaning is defined in the document, in terms of abstractions rather than in terms of operational behavior. The result is more robust standards, those that have wider applicability, that can be used for more purposes, and that create a more vibrant and extensible web.

1. Syntax
2. Vocabulary
3. Policy
   

Google's documentation shows support for both microformats and RDFa. It follows the hReview microformat syntax with small vocabulary changes (name vs fn). Support for RDFa syntax, in theory, means support for vocabularies that anyone makes; but in practice, Google is starting with a clean slate: data-vocabulary.org. That's a place to start, though it doesn't provide synergy with anyone who has uses FOAF or Dublin Core or the like to share their data.

The policy questions are perhaps the most difficult. Structured data is a pointy instrument; if anyone can say anything about anything, surely the system will be gamed and defrauded. Google's rollout is one step at a time, starting with some trusted sites and an application process to get your site added. The O'Reilly interview with Guha and Hansson is an interesting look at where they hope to go after this first step; if you're curious about how this fits in to HTML standards, see Sam Ruby's microdata.

While issues remain--there are syntactic i's to dot and t's to cross and even larger policy issues to work out--between Google's rollout and Yahoo's searchmonkey and the UK Central Office of Information rollout, it seems that the industry is ready to take on the challenges of using structured data in search engines.

We can be followed on identi.ca/w3c, as well as twitter.com/w3c.

Unfortunately, hAudio changed out from under me between when I started and when I finished. So this time, a simple search found the music ontology and I tried it with RDFa, which lets you use any RDF vocabulary in HTML*. I'm mostly pleased with the results:

1. from A Song's Best Friend_ The Very Best Of John Denver [Disc 1]
   by John Denver
   Poems, Prayers And Promises
2. from WOW Worship (orange)
   by Compilations
   Did you Feel the Mountains Tremble
3. from Family Music Party
   by Trout Fishing In America
   Back When I Could Fly

The album names come before the track names because I didn't read enough of the the RDFa primer when I was coding; RDFa includes @rev as well as @rel for reversing subject/object order. See an advogato episode on m3uin.py for details about the code.

The Music Ontology was developed by a handful of people who staked out a claim in URI space (http://musicontology.org/...) and happily took comments from as big a review community as they could manage, but they had no obligation to get a really global consensus. The microformats process is intended to reach a global consensus so that staking out a claim in URI space is superfluous; it works well given certain initial conditions about how common the problem is and availability of pre-web designs to draw from. Perhaps playlists (and media syndication, as hAudio seems to be expanding in scope to hMedia) will eventually reach these conditions, but the music ontology already meets my needs, since I'm the sort who doesn't mind declaring my data vocabulary with URIs.

My view of Web architecture is shaped by episodes such as this one. While giga-scale deployment is always impressive and definitely something we should design for, small scale deployment is just as important. The Web spread, initially, not because of global phenomena such as Wikipedia and Facebook but because you didn't need your manager's permission to try it out; you didn't even need a domain name; you could just run it on your LAN or even on just one machine with no server at all.

In an Oct 2008 tech plenary session on web architecture, Henri Sivonen said:

I see the Web as the public Web that people can access. The resources you can navigate publicly. I define Web as the information space accessible to the public via a browser.
If a mobile operator operates behind walls, this is not part of the Web.

I can't say that I agree with that perspective. I'm no great fan of walled gardens either, but freedom means freedom to do things we don't like as well as freedom to do things we do like. And architecture and policy should have a sort of church-and-state separation between them.

Plus, data interchange happens not just at planetary scale, but also within mobile devices, across devices, and across communities and enterprises of all shapes and sizes.

I've gone a little outside the scope of current standards; RDFa has only been specified for use in modular XHTML, with the application/xhtml+xml media type, so far.

See also:

• Feb 2009: Palm webOS approach to HTML extensibility: x-mojo-*
• Aug 2008: The details of data in documents: GRDDL, profiles, and HTML5

As part of a series of interviews with W3C Members to learn more about their support for standards and participation in W3C, I asked Rotan Hanrahan (MobileAware's Advisory Committee Representative at W3C) some questions.

Q. How is MobileAware currently participating in W3C?

A. In addition to nearly a decade of participation in W3C’s ubiquitous Web and device independence work, MobileAware is a founding sponsor of the W3C’s Mobile Web Initiative, in which we chaired the Device Description Working Group (DDWG), culminating in the creation of a new W3C Recommendation (Device Description Repository Simple API). The company is proud to have edited and contributed to several W3C publications over the years and to have participated in many W3C events including the hosting of, or participation in, various Workshops. It is important to MobileAware that participation is active and progressive. Our goal is to help extend the Web beyond the desktop.

Q. How do standards benefit MobileAware, and what W3C standards are of particular importance? Do your customers value standards support?

A. MobileAware is a specialist company, dealing with technical challenges that few appreciate and even fewer understand. We work in an ecosystem of specialities. To make all these work together, we have to establish some common ground. Interoperability doesn’t just happen; you have to make it happen. For us, agreement on the definition and use of the delivery context (for mobile in particular) was a key requirement. The delivery context is the set of all factors that could affect the adaptation and/or delivery of content or services via Web technology. It’s a central concept for many of our products. Our customers appreciate that we have shared our expertise with others and, equally important, we have listened to those who were willing to share with us. Furthermore, the W3C has produced many guides and best practices, which help one to judge the quality of solutions in this increasingly competitive market.

Q. Can you share any success stories about the use of Web standards?

A. Success was quick coming to MobileAware. In the months leading up to the founding of the company, before Y2K fever had set in, we had become aware of this new idea called XHTML modularization. It promised a way to extend into new platforms, and we were excited by the possibilities, especially as we prepared for our bold step to create a new platform for the mobile Web. We built upon XHTML using this new idea of modularity, adding the necessary metadata and structures that would empower authors to create content that adapts to new contexts, especially mobile. It was one of the most important decision we ever made, and extremely successful.

Q. How about any challenges you or your customers have faced when trying to use Web standards?

A. The biggest problem we have faced, and still face today, is decoupling the Web from desktop browsers. For example, we regularly face puzzlement from customers who wonder why a heading on one mobile browser looks so different from the same heading on another mobile browser. Explaining that “heading” is a conceptual notion that may be rendered differently in different contexts can be baffling to people from the pixel-perfect desktop world. Different presentation is an inevitable consequence of differing delivery contexts. Fortunately, our customers quickly learn to embrace this diversity, especially when we provide them the tools to do so.

Q. Many content adaptation products have been introduced or promoted in the mobile Web ecosystem as short-term to mid-term solutions to make the Web at large available on legacy devices with poor browsing capabilities. New mobile devices ship with more powerful browsers. How do you see the role of content adaptation for mobile devices in five years from now?

A. Early content adaptation solutions were motivated by the need to work around deficiencies and extreme variance in new browsers, especially those on mobile devices. These are the short-term to mid-term solutions that you hear about. Adaptation has moved on. Diversity is increasingly seen as a good thing, an opportunity. Deficiencies are becoming a thing of the past. Indeed, many mobile Web-enabled devices have capabilities that you won’t find on many desktops, such as touch-screens, motion sensitivity, geo-location and more. Users are becoming more demanding, looking for personalized experiences, greater interactivity and more combinations of technology/service. Diversity is here and it is growing. In 5 years we will be totally immersed in it. The ever-present challenge is to be able to adapt to this diversity.

Q. Copyright infringements and security/privacy concerns are two examples of issues raised by Web publishers against the deployment of third-party transformation proxies by mobile network operators. How can the diverging needs of the actors of the delivery chain be addressed to the end user's final benefit?

A. Transformation proxies generally sit between the origin server (author) and the Web client (user). They act on behalf of the user or on behalf of the provider of the communication service. Adapting proxies seldom act on behalf of the author. In the case of legacy content, the authors did not anticipate the possibility of adaptation and so left no guidance as to how they might like this to occur. They did not, for example, identify which parts of their documents might be optionally removed in order to fit onto smaller screens. Some proxies may take this absence of author guidance to mean that they have a free license to do what they want with the content. Meanwhile, there are many adapting sites on the Web today that will adapt content in accordance with the author’s wishes (and the browser’s abilities and user’s preferences) to deliver a good Web experience. But this is being thwarted by some proxies that will masquerade as different devices, confusing the server by presenting it with false delivery contexts. What the proxy eventually delivers to the user is often poor in comparison to what the adapting origin server would deliver, because the proxy does not have the advantage of knowing the author’s intentions, including presentation, security and privacy concerns. In many cases the key problem is lack of respect for the efforts, rights and preferences of authors and users. Thankfully, efforts within the W3C MWI are proving guidance on how proxies can use available technology to be respectful of these concerns, though we will have to rely on the goodwill of the industry for such guidance to be universally applied.

Q. Most Web developments (think applications, widgets) are still either targeting the desktop world, or developed for specific classes of mobile devices from scratch. On the one hand, adaptation of a desktop site to fit mobile devices is often viewed as a costly and constrained work item. On the other hand, new capabilities offered by mobile devices seem to be mobile and platform specific. Can a true ubiquitous approach be considered? How is the mobile world impacting the desktop world?

A. Part of the problem is assuming that the starting point is the desktop. Sure, if a desktop site already exists, there is a huge temptation to assume that you will lose a lot of investment if you don’t make it the starting point of your mobile site. The results of this sort of thinking can be disastrous. Generally, when you look closely at a desktop site and you strip away the features that make it particularly attractive on desktop browsers, you reveal the true essence of your site. This is where you start, and in many cases this essence is in your back-end solution, not the presentation layer. The mobile Web experience is not just a miniaturized version of the desktop. You have to consider not only the context of the device (size, capabilities, limits etc.) but also the context of the user (in transit, in a hurry, focused etc.). While you may be re-using many of the familiar Web technologies such as HTTP and various markup languages, you will find that the workflow needs to change, the emphasis will change, and expectations need to change. The Web technologies will be ubiquitous, but not necessarily used in the same way. Certainly, for business users of the mobile Web, the browser is less of a surfboard and more of a machete.

Q. Content transcoding proxies deployed by operators can improve the user experience of many Web sites. However, when content providers simultaneously make efforts to make their site work on a mobile device, conflicts can arise. How would you advise both operators and content providers to manage this situation?

A. There are some simple ways that a transcoding proxy can avoid interfering with sites that already deliver contextually-appropriate content. Sampling is the easiest solution. For example, a test request from what appears to be a mobile browser may result in a mobile content response, in which case the proxy can record that this site should not be adapted further. Non-adapting sites can be re-sampled at intervals to see if they have upgraded to adaptability. Observing the returned HTTP headers also provides vital clues, especially the Vary header and No-Transform directive. Generally, proxies should err towards the least interference. Servers should, of course, also emit headers that can be used by proxies to influence their behaviour. Proxies should also announce their presence, so that origin servers have some way of recording proxied traffic (which may encourage desktop site owners to give more attention to the needs of mobile Web users). Users should also be made aware of the proxy, especially if there are security/privacy concerns. The W3C Mobile Web Best Practices group has being doing a lot of work in this area, and has been encouraging public discourse to highlight the issues and possible solutions.

Q. There is no precise definition of the term "mobile" but it seems to be shifting from a concept tied to a physical device to something closer to freedom, as it carries the expectation that a task can be started on a device and pursued on another one. Are new technologies needed to cope with this use case?

A. The DDWG charter described mobile devices as Web-enabled devices that are normally used away from fixed locations and are manufactured specifically to be portable and usable while being moved. While session mobility (migration) is technically possible, we currently don’t see much demand for it in solutions that are context-aware. This is because the workflow tends to vary, and different contexts will have different entry/exit points, so migrating to a different context changes the dynamics of the workflow. This can be confusing. Dealing with this is a challenge for Web applications, but as the browser becomes more embedded in our surroundings, session migration will be important. At this point we will be moving beyond content adaptation into application adaptation. So yes, we will need new technologies.

Q. What does MobileAware value in its participation in W3C?

A. This is a deep question, one I’ve been asked before in a different context, and I’m happy to repeat what I said at that time: The W3C is a facilitator for product making. The venue (being the environment in which Members operate) is a key factor in this facility and is the primary justification for the basic cost of membership. On top of this are the enablers of product development, namely the resulting specifications, for which the members are expected to expend additional resources for their creation.

Additionally, there are other valuable services of the W3C that act as the "glue logic". To start, the test suites and validators serve to engender quality into the W3C products. The feedback mechanism of public discourse ensures relevance to the Web community while also providing an essential further check on the validity/correctness of specifications.

Then we have the ongoing outreach and education, which in a way is akin to a marketing exercise motivated not by profit but by a sense of mission. The W3C also provides a locus of crystallization for exploratory work through its many workshops, IGs and the many talks by W3C staff as reported in our regular W3C bulletins. The W3C site provides relevant archival services, not only as an authoritative reference but also as an historical record showing how much of the Web architecture has evolved (a history from which we should draw valuable lessons). The W3C sometimes provides a service of industry/community representation, such as the times when W3C takes a message to world governments or defends against unfair patents, which is perhaps something that no individual member would want or be able to do. The W3C provides a badge of trust, which can be a source of confidence and assurance to Member's customers, enabling many niche solutions to emerge without the potentially negative label of "proprietary". In this way, the W3C helps the Web to evolve in novel ways. The W3C even demonstrates how to use the technologies through its open source work, with several very useful free tools. And I could go on...

One of the things that makes these truly valuable is that nobody (as yet) has attempted to place a monetary value on them. From the community perspective, the services of the W3C are orthogonal to the commercial world. The specifications are freely available and unencumbered by IP protection, the validators are always online for immediate use, the archives are searchable by anyone, the workshops are open to anyone who has something worthwhile to contribute (and the results/papers are always free to view), the outreach is fair and global. About the only thing that comes at a price is active W3C membership (i.e. fees and the costs associated with doing real work in the WGs), and MobileAware has been an active member for nearly a decade. We value our participation.

Q. Where would MobileAware like to see W3C improve?

A. There is a danger that W3C tries to take on too much. The Web is now an essential part of the fabric of our technologically advancing global community, and its reach is immense. It would be challenging for the W3C to try to take the lead in everything that has some Web aspect to it. Instead, it may be time to refine the focus, concentrate on the architecture of the Web and be ready to let some activities find a new home in existing or new organisations. The work of the W3C needs to be streamlined to keep up with the demanding pace of the Web. Goals should be more realistic, timeframes shorter, activities more flexible. There should be willingness to stop when necessary. Anything that takes more than two years from the point when the requirements are agreed is either too big or just not worth pursuing. We don’t have to do everything in a single bound; we can make this journey in small steps, and lots of them.

Q. MobileAware chaired one of the W3C working groups for several years. Why would a small company take on such a demanding role?

A. I had the personal privilege of working with many skilled, intelligent, wise and experienced people from many member companies (partners, competitors, observers, enthusiasts and more) over many years in W3C. Whether their respective companies have thousands of employees, or just a few dozen, it makes no difference so long as they can contribute their speciality to help the Web reach its full potential. MobileAware helped to highlight several pressing issues during the formation of the MWI, and when we were asked if we would help solve those issues, it was clear that we were at the right place at the right time. I may be the face of MobileAware in the W3C, but I am supported by a team of experts from our offices around the world, and with the right support any W3C member, large or small, can make a difference. For us, the reward has been to see how the mobile Web has become an integral part of the greater Web, and the challenges are being addressed day by day with abundant enthusiasm. It’s good to be here.

Many thanks to Rotan for his answers.

Sam asked me to look at the results of running the demonstration through the HTML5 validator. It doesn't pass it and that's intentional. I'm not sure why HTML5 excludes the complex constructions of Ruby or why I can't use unit lengths in width or height. Boolean attributes in HTML5 can't use the values "true" or "false" and I can't get myself to accept that fact. There are probably ugly stories around those. I needed a way to link to external captions. And there is RDFa.

The main point of the demonstration is to see those technologies working and interacting together. It has been a hard road to get where we are today and there is still so much work to do, but let's not forget that it's fun to see those things working.

The group is looking into a lot of (!) metadata formats for media on the web: EXIF, ID3, MediaRDF, MPEG-7, XMP, etc. As part of an "Ontology for Media Objects", the group is defining a small set of commonly shared properties - the "Dublin Core of Multimedia".

In addition, the group is working on an API for accessing these properties, independent of the underlying metadata format. The API uses the ontology, that is the mappings between the common properties and existing formats. In that way, you will be able to get the author, creation date or keyword information of a media object, across images, videos and audio files of all kinds. Life can be so easy ...

Please have a look at the current version of the mappings and provide feedback to the working group. Getting your input and reaching consensus with developers and users of metadata formats will be a key to the success of this work.

Written by Felix Sasaki.

Last night, as I was thinking about what to highlight in this post, I concluded that a screencast tour might be more interesting. It is a bit long (10 minutes) but covers some of the key features of the redesign. There is also a page about the redesign with more details about features and known limitations.

I would like to thank the W3C Systems Team for their dedication to making this happen. We implemented the site using a combination of off-the-shelf tools and some home-grown glue. I look forward to blogging about those tools and the site itself over the next few weeks.

We need a lot more content for pages like the technology introductions. You can help. If you would like to write a few paragraphs about a technology that interests you, we will do our best to integrate the material into the site. Our page about the redesign explains more.

Let us know your thoughts, and enjoy the beta.

Update 2009-04-14: I have created a page to track comments.

An organization like the FAO has an accumulated knowledge that goes back to several decades in the form of, for example, thesauri or glossaries. The upcoming W3C SKOS specification provides a tool to encode such thesauri, glossaries, terminologies in a standard, machine readable format. By publishing it in a standard format, not only is the thesaurus usable for FAO’s own purposes but it can also be reused by anybody else on the Web. This is what the FAO has done by publishing their Agrovoc Thesaurus in SKOS, and base their search interface on that thesaurus, too. Similarly, other institutions like libraries can publish their catalogues, subject headings, glossaries, etc, using the same format, providing a web of interrelated concepts and terms that could be used to organize and integrate data overall. This can be an important step in the advancement of the (Semantic) Web.

For further details on the FAO application, please look at the Semantic Web Case Study published on the W3C site (courtesy of Gauri Salokhe, Margherita Sini, and Johannes Keizer). And look at the SKOS specification (or the SKOS Primer) if you want to know more technical details!

Just after the mobile buzz at Web Directions North and the TAG declared victory on how to build The Self-Describing Web with URI-based Extensibility , I get some details on how Palm is building on the open web platform:

A widget is declared within your HTML as an empty div with an x-mojo-element attribute.

<div x-mojo-element="ToggleButton" id="my-toggle"></div>

Oh great; x- tokens... aren't those passe by now?

The suggestion in the HTML 5 draft is data-* attributes. The ARIA draft suggests @role. The Palm design looks like new information for issue-41, Decentralized-extensibility, in the HTML WG.

Anybody know how frozen the Palm design is? Or if they looked at ARIA, data-* or URI-based namespaces?

I'm always pleasantly surprised when I hear that, what started as a 10 minutes demonstrator of the semantics attached to HTML, is actually used as a tool by a number of developers.

With a name such "semantic data extractor", it was a bit of a shame that the tool didn't highlight the usage of GRDDL or RDFa on pages that use either of these technologies; I have just added detection of both of these to the extractor.

As a bonus, I have also added detection of non-semantic markup: at this time, it will detect purely-wrapping <div>, empty <span>, and tables with a single row or a single column (which have good chances to be layout tables); if you have suggestions for detecting other non-semantic markup, let me know!

I don't know if I should be happy or sorry that this didn't actually happen, but I am quite happy with the two days of the great discussions at the workshop, and the plans we have started to make to follow-up on these points.

We've just released today the report that summarizes the discussions and conclusions of the workshop (with an accompanying press release), but it's hard to make justice in a few pages to all the energy and rich exchanges that went on during the meeting among the 90 or so participants, fed by the 72 submitted papers.

Among the identified next steps, the creation of one or more Incubator Groups to continue to work initiated on interoperability mapping, privacy best practices, and decentralized architectures is moving ahead, supported by the ongoing discussions in the publicly archived mailing list <public-social-talk@w3.org>, where already 80 people have subscribed to follow up generally on the conversations started in the workshop.

If that topic is of interest to you, make sure to join that list, and stay tuned as the concrete next steps are being implemented!

That was more than a decade ago. Browsers, meanwhile, have made incredible progress at gracefully rendering even the most broken web page. And that is a good thing.

Does this make validation and quality checking of Web pages moot? Of course not. There are many more incentives to build great standard-compliant websites: ease of maintenance, show of professionalism, or, in the words of Zeldman, Client who saves $5,000 buying cut-rate non-semantic HTML will later spend $25,000 on SEO consultant to compensate.

It makes me curious, however, to know what are the real-life arguments in favor of valid, standard code today. Do you have an untold story of validation getting you rid of an awful rendering glitch? Real-life accounts of a search engine bump achieved by fixing the syntax of you HTML <head>? A typo in a CSS stylesheet that hours of glancing at code didn't show, but the validator did? A forgotten alt that would have lowered your search rank for an important keyword, or cost a big fee for non-accessibility?

Use the comments below to share and discuss your experience - we'll update our outdated “Why Validate?” doc with the best examples.

Sorry. You must have JavaScript enabled to view this page. Click the BACK button below or enable JavaScript in your browser preferences and click TRY AGAIN.

Unfortunately, our days of vexation aren't over yet.

First, the Element Traversal specification isn't supported in the latest final product versions of Firefox or Internet Explorer for example. I didn't check with Safari but Opera does support it. Some of those, if not all, will support the specification in their product releases of 2009.

Second, as we all know, users take time to upgrade to the latest versions of Web browsers, so the Web developers won't get to enjoy the specification out of the box on the Web for sometimes.

So, should we forget about using Element Traversal? Well, no, not quite. Given the simplicity of the functions, you can easily write a work around. I developed et.js, Element Traversal for everyone while musing today around the future of ECMAScript. You don't get to enjoy the low implementation footprint of Element Traversal but it works at least. I didn't test it in all browsers but the page contains a self-test. If it doesn't work for you, let me know.

Joyeux Noël.