On July 27th, 2010 we made the first official release on Unicorn. We are elated with the response from the community. Within two days after the announcement we received 7 additional translations.

There are already a couple new checkers in the works, a few being discussed and a number of interesting suggestions for more such as creating accessibility and jslint checkers. Check out the code, write a checker if you are inclined, provide feedback or donate. Stay tuned and thank you.

Last month's Augmented Reality on the Web workshop in Barcelona has sparked a good deal of debate within and around W3C. As the final report shows, the workshop brought together many different companies and organizations working on or with a direct interest in the field of Augmented Reality — but how can W3C help in this area?

One outcome is clear: we need a method for representing data about points of interest and proposals are advancing to achieve this in a new POI Working Group. Quite what data needs to be represented concerning Points of Interest depends on who you ask. For some it's a question of annotating a given point on the Earth's surface where the longitude, latitude and altitude are all key identifiers. For others it's more a question of the point at a given distance and angle from an object that may or may not be static as seen by an observer who may themselves also be moving.

Different communities are involved here: as well as the augmented reality community, the linked data community has a keen interest. There are other facets to the discussion too and this is what will make the POI working group's work interesting!

The workshop also recommended that a new POI WG should go further and consider the wider picture of how AR does, or might, relate to the Web. Privacy is a major concern; device APIs are critical enablers; do CSS and SVG have sufficient power to support AR functions? Even the use of HTTP as a transport mechanism is questioned by some given the real time nature of AR.

To join the debate about all this, please subscribe to the Point of Interest mailing list and keep an eye out for calls for review of the charter in the near future.

From the very first release of the cheatsheet, I’ve received requests to include the various new elements and attributes of the HTML5 specification in the cheatsheet. As a reminder, the cheatsheet is a mobile-friendly Web application that provides a compilation of useful knowledge extracted from W3C specifications

At long last, I’ve finally managed to integrate these new elements in the latest release of the cheatsheet, where you will now find all the new, changed, obsolete and removed elements and attributes in HTML5 highlighted:

All the data are extracted from HTML: The Markup Language Reference, the specification maintained by Mike Smith that describes the markup aspects of HTML5.

As always, this comes with a number of bug fixes, UI improvements (thanks to Sorin Stefan), and this release is both available in the Web version and in the Android application.

QR Code for cheatsheet on the Android market

Obviously, I’m expecting to now get requests for another spec “du jour” (CSS3 anyone?), which clearly is in my roadmap — but as always, I’m very much interested in getting others to contribute to the work.

Feedback, comments and suggestions are very much appreciated!

July 9, 2010

I reported in The Mission of W3C that a major focus of W3C is to Strengthen our core mission. This blog entry elaborates.

Since the Web is central to everything (see also The Expanding Web Platform), it is not too surprising that we get involved in standardizing numerous aspects of Web infrastructure. Today we have over 70 groups that are providing standards in diverse areas. Evidently, some of these groups have greater impact on the utility of the Web than others. Also, some of them are more advanced/complex/difficult than others. If we apply an equal amount of effort to each working group, we will sub-optimize the Web by not applying sufficient resource on those that are most crucial. So we prioritize.

Every time we make an incremental change in our effort – such as when we start a new working group or expand the scope of requirements – we are making an incremental prioritization decision. In our “core mission task force” we are taking a step back and looking at the ensemble of our activity. Do we know which small number of the 70 groups are the most important? Are we applying sufficient resource and attention to them to guarantee the greatest possible success?

As our task force characterizes projects into core and non-core, one might ask what difference it makes.

There are many reasons that a non-core standard might have migrated to W3C. Some of them are:

• The standard is a natural adjacency of a core standard

• W3C houses a team who are knowledgeable technologists who can best shepherd the standard

• The standard is a candidate to be core in the future

… among other reasons. These are actually sensible reasons. So we will absolutely continue to serve the industry and convene those standards groups.

But for core standards we must have a higher target of quality. It is not sufficient to work with the industry to create the standard. We must assure quality of the standard, develop it on schedule, help make sure that it has the right feature set, work on testing strategies, provide training, and help people appreciate the value. Our core mission task force might not change the list of working groups. But it will change emphasis. For items in core, we will provide supreme effort to ensure quality, the right feature set, timeliness, and market support.

Last month I spent a week in Silicon Valley. The importance of giving top attention to core was re-inforced.

Our largest working group is the HTML5 working group. Literally hundreds of people participate in the W3C HTML5 working group.

Many of them work in Silicon Valley. So I met with many of them. They come from a cross-section of companies: browser vendors, web publishers, tools providers, application vendors, security firms.

Since HTML5 is core, it is important that we as a community get it “right”. Since it is central to the next generation web, it evokes strong opinions about what it means to “get it right”. And as I listened to the opinions they are all well reasoned and based on knowledgeable and sensible views of how the future web will evolve.

While they are all reasoned, knowledgeable, and sensible – that does not mean that everyone agrees. Not at all! Nor should we expect agreement for something so central – given that different organizations have different priorities.

Therein, lies W3C's imperative to provide the right amount of attention to strengthen our core. We bring diverse stakeholders to the table and create the environment for the industry to agree on this critical standard. There is still more work to be done. There are technical issues, testing issues, and disagreements that need to be resolved. It is our commitment to work with all stakeholders to drive this forward in a professional way, and ensure that we have the right feature set, quality, timeliness, and market support.

Before taking a short vacation starting last week I announced a public survey: Making W3C the place for new Web standards. The survey is part of the work of the task force I'm chairing that has a number of goals:

• Make W3C an attractive venue for developing Web technology.
• Make it extremely easy for individuals (not just organizations) to participate actively in the W3C community.
• Create a smooth path from "new idea" to "standard", while not expecting or requiring all products to use all mechanisms.
• Promote outreach to communities not yet connected to W3C to learn from them and encourage them to bring new ideas to W3C.

The survey is part of our initial data-gathering effort. In this first phase of our work, we want to identify perceived and real barriers to participation, the W3C value proposition to audiences interested in bringing new work to W3C, and some use cases we should be sure to address (or, if we don't, at least document while prioritizing).

We are doing this work in public (see the wiki and mailing list). We are having a lot of conversations with people to flesh out the use cases, list of barriers, etc. so that in the next phase, we draft proposals that have a chance of meeting real needs. We are starting to write down ideas and proposals but they are very drafty at this point, as well as incomplete. Our aim is to come up with proposals that address use cases, lower barriers to participation, and enhance the W3C value proposition. I expect to provide periodic updates via this W3C blog between now and November, when we present our proposals to the W3C Membership.

In the meantime, there are already 67 responses to the survey, lots more than I expected to find right after vacation. If you have stories to share with W3C that you think will help us improve the organization, please take a moment to take the survey. Thanks!

For those of you interested in deploying RDF on the Web, I'd like to draw your attention to three new proposed standards from IETF, "Web Linking", "Defining Well-Known URIs", and "Web Host Metadata", that create new follow-your-nose tricks that could be used by semantic web clients to obtain RDF connected to a URI - RDF that presumably defines what the URI 'means' and/or describes the thing that the URI is supposed to refer to.

Most semantic web application developers are probably familiar with three ways to nose-follow from a URI:

1. For # URIs - for X#F, the document X tells you about <X#F>
2. When the response to GET X is a 303 - the redirect target tells you about <X>
3. When the response to GET X is a 200 - the content may tell you about <X>

In case 3, X refers to what I'll call a "web page" (a more technical term is used in the TAG's httpRange-14 resolution). One of the new RFCs extends case 3 to situations where the RDF can't be embedded in the content, either because the content-type doesn't provide a place to put it (e.g. text/plain) or because for administrative reasons the content can't be modified to include it (e.g. a web archive that has to deliver the original bytes faithfully). The others cover this case as well as offering improved performance in case 2.

Web pages as RDF subjects

Before getting into the new nose-following protocols, I'll amplify case 3 above by listing a few applications of RDF in which a web page occurs as a subject. I'll rather imprecisely call such RDF "metadata".

1. Bibliographic metadata - tools such as Zotero might be interested in obtaining Dublin Core, BIBO, or other citation data for the web page.
2. Stability metadata - for annotation and archiving purposes it may be useful to know whether the page's content is committed to be stable over time (e.g. this has changing content versus this has unchanging content). See TimBL's Generic Resources note.
3. Historical and archival metadata - it is useful to have links to other versions of a document - including future versions.

All sorts of other statements can be made about a web page, such as a type (wiki page, blog post, etc.), SKOS concepts, links to comments and reviews, duration of a recording, how to edit, who controls it administratively, etc. Anything you might want to say about a web page can be said in RDF.

Embedded metadata is easy to deploy and to access, and should be used when possible. But while embedded metadata has the advantages of traveling around with the content, a protocol that allows the server responsible for the URI to provide metadata over a separate "channel" has two advantages over embedded metadata: First, the metadata doesn't have to be put into the content; and second, it doesn't have to be parsed out of the content. And it's not either/or: There is no reason not to provide metadata through both channels when possible.

Link: header

The 'Web Linking' proposed standard defines the HTTP Link: header, which provides a way to communicate links rooted at the requested resource. These links can either encode interesting information directly in the HTTP response, or provide a link to a document that packages metadata relevant to the resource.

In the former case, one might have:

Link: <http://xmlns.com/foaf/0.1/Document>;
  rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"

meaning that the request URI refers to something of type foaf:Document. In the latter case one might have:

Link: <http://example.com/about/foo.rdf>;
  rel="describedby"; type=application/rdf+xml

meaning that metadata can be found in <http://example.com/about/foo.rdf>, and hinting that the latter resource might have a 'representation' with media type application/rdf+xml.

Host-wide nose-following rules

The motivation for the "well-known URIs" RFC is to collect all "well-known URIs" (analogous to "robots.txt") in a single place, a root-level ".well-known" directory, and create a registry of them to avoid collisions. The most pressing need comes from protocols such as webfinger and OpenID; see Eran Hammer-Lahav's blog post for the whole story.

For linked data, .well-known provides an opportunity for providing metadata for web pages, as well improving the efficiency of obtaining RDF associated with other "slash URIs", what is currently done using 303 responses.

Ever since the TAG's httpRange-14 decision in 2005, there have been concerns that it takes two round trips to collect RDF associated with a slash URI. While some might question why those complaining aren't using hash URIs, in any case the "well-known URIs" mechanism gives a way to reduce the number of round trips in many cases, eliminating many GET/303 exchanges.

The trick is to obtain, for each host, a generic rule that will transform the URI at that host that you want RDF for into the URI of a document that carries that RDF. This generic rule is stored in a file residing in the .well-known space at a path that is fixed across all hosts. That is: to find RDF for http://example.com/foo, follow these steps:

1. obtain the host name, "example.com"
2. form the URI with that host name and path "/.well-known/host-meta", i.e. "http://example.com/.well-known/host-meta" (see here)
3. if not already cached, fetch the document at that URI
4. in that document find a rule generically transforming original-URI -> about-URI
5. apply the rule to "http://example.com/foo" obtaining (say) "http://example.com/about/foo"
6. find RDF about "http://example.com/foo" in document "http://example.com/about/foo"

The form of the about-URI is chosen by the particular host, e.g. "http://example.com/foo,about" or "http://about.example.com/foo" or whatever works best.

Why is this fewer round trips than using 303? Because you can fetch and cache the generic rule once per site. The first use of the rule still costs an extra round trip, but subsequent URIs for a given site can be nose-followed without any extra web accesses.

A worked example can be found here.

Next steps

As with any new protocol, figuring out exactly how to apply the new proposed standards will require coordination and consensus-building. For example, the choice of the "describedby" link relation and "host-meta" well-known URI need to be confirmed for linked data, and agreement reached on whether multiple Link: headers is in good taste or poor taste. (Link: and .well-known put interesting content in a peculiarly obscure place and it might be a good idea to limit their use.) Consideration should be given to Larry Masinter's suggestion to use multiple relations reflecting different attitudes the server might have regarding the various metadata sources: For example the server may choose to announce that it wants the Link: metadata to override any embedded metadata, or vice versa. Agreement should be reached on the use of Link: and host-meta with redirects (302 and so on) - personally I think it would be a great thing as you could then use a value-added forwarding service to provide metadata that the target host doesn't or can't provide.

This is not a particularly heavy coordination burden; the design odds-and-ends and implementations are all simple. The impetus might come from inside W3C (e.g. via SWIG) or bottom-up. All we really need to get this going are a bit of community discussion, a server, and a cooperating client, and if the protocols actually fill a need, they will take off.

For past TAG work on this topic, please see TAG issue 62 and the "Uniform Access to Metadata" memo.

The report from the W3C Workshop on Future Standards for Model-Based User Interfaces is now available. The workshop took place in central Rome on 13-14 May 2010, and focused on ideas for making it easier to create Web applications that can be delivered across many kinds of devices and that adapt dynamically to the context.

To achieve this, it is necessary to separate out different kinds of design concerns, and this is where models come in. There has been a steady stream of research work in this area for many years (including the W3C MBUI Incubator Group), and the workshop was held to bring together researchers to examine whether it is now timely to launch standards work. The workshop participants recommended that W3C consider starting a new Working Group on meta-models as a basis for exchange between different markup languages for model-based authoring tools. We hope to make a start on this later this year with help from the EU Serenoa project.

I want to express my thanks to my co-chair Fabio Paternò, all of the participants and to W3C and to the CNR-ISTI HIIS Laboratory for hosting the workshop.

So where are we (that "we" meaning the CSS Working Group) on CSS 2.1? In short, we're making fast and excellent progress:

• we are currently resolving the last outstanding issues ; almost all our weekly conference calls are entirely dedicated to CSS 2.1
• the Test Suite is near completion ; the Working Group has decided, given the size of the Test Suite, that it's not realistic to review individually all tests before saying the Test Suite is completed. We will declare the Test Suite ready for implementation reports and will fix individual bugs when reported buggy by testers, browser vendors, the community, whoever. On a more personal note, I think it's the only reasonable way of dealing with a Test Suite that contains thousands and thousands of tests, some of them rather complex not only to write but also to understand when you read them. Otherwise, the review and validation process of all these tests alone will take ages...
• given the recent changes in the spec - we resolved a lot of issues some of them pretty complicated - we may have to go back to Last Call Working Draft and then back to CR again. That's not a problem and can be relatively fast.
• the current CR exit criteria - that we don't plan to change - are very clear (see conditions 4 and 5). The CR period could be a bit long though; we'll see.
• the Test Suite and the CR should be available at same time and that time should be, as planned by the WG, after the summer. That should leave us enough time to reach Proposed Recommendation before the end of the year, as expected.

To the people who could complain about the duration of this process and the time needed to make this spec appear as a REC, let me say that we have a lot, really a lot of work here. The WG focuses almost solely on CSS 2.1 at this time and that's not recent. 2.1 must be released as a Web Standard because that's one of the current cornerstones of the architecture of the World Wide Web. We cannot make the next steps, CSS 3 even module by module, happen without 2.1 before.

In summary, we're on track. As expected. No reason to worry.

Thanks.

Daniel Glazman, W3C CSS Working Group, Co-chair

Following the successful W3C Workshop: Augmented Reality on the Web in Barcelona last week, work is now underway to establish a Working Group to develop one or more Recommendation Track documents to encode data about Points of Interest. An important standard already exists in this area (KML) which was developed for and is used in Google Earth, but at least two groups have developed extensions to KML to meet their use cases (ARML and KARML). Outside the field of Augmented Reality there are other areas where a standardized, interoperable method of describing real world locations is called for. Primary among these non-AR fields is linked data, especially linked data published by governments, where tying the data to geographical areas can be the key to making sense of what the data is telling us.

A full report on the workshop is in preparation and will be published in the very near future however, a public mailing list has already been established and exists to act as a communication channel for those wishing to help create the charter for the new group and, all being well, participate in it.

We are aiming to make the charter available for review next month with a view to holding the kick off face to face meeting in October, collocated with ISMAR - such a timetable, of course, is entirely dependent on whether the WG charter is approved by the W3C Membership.

Back in November, I announced the first release of the W3C cheatsheet for Web developers — a compact Web application that provides quick access to useful information from various W3C specs.

Making that Web app mobile friendly has always been one of its design goals: it uses a very compact layout, the JavaScript-based auto-complete search was tweaked to work reasonably well with mobile keyboards (including virtual keyboards), it uses HTML5’s ApplicationCache to be usable off-line in browsers that support it.

I've been exploring the convergences and tensions among Web apps and native applications (in particular on the mobile platform) for the past few months, and one of the interesting object that I've seen floating in the middle of these apparently opposing camps is the notion of downloadable apps built with Web technologies.

One of the W3C Working Groups, the Web Applications Working Group is developing a stack of specifications to make it easier to develop applications with widgets.

There are quite a few similar efforts in various communities: Nokia’s Web runtime engine, Firefox add-ons, Chrome extensions, and Safari extensions to name a few. It will be interesting to see if all these efforts end up converging toward the current (or a future revision of) the W3C widgets specs.

Coming back to the main topic of this blog post, as part of my musings on Web apps and native apps, I've been looking into turning the W3C Cheatsheet into a “native application”; owning an Android phone, I've been focusing on that platform for purely selfish reasons, and thanks to the simplicity of the PhoneGap framework, compiling the cheatsheet into a downloadable application for Android has proved extremely easy.

I've already found some different optimizations between the Web version and the “compiled” one, which I'm hoping to summarize in the future; but the main point today is that I have published that compiled application on the Android Market, where it is available starting today. Search "W3C cheatsheet" or use the QR code to get there.

Obviously, this is not particularly an endorsement of Android, even less so an endorsement of the world of applications markets; a growing number of people seem to see these markets as in opposition to the Web — my personal opinion is that they're probably complementary, the same way a Web portal or a social bookmarking service are complementary to search engines. This is a fast moving space, I hope to learn more about it, and I look forward to sharing more experience (including with W3C groups working on the technology).

The application is available in two flavors: free and for a contribution. They are identical and I expect them to remain identical for the foreseeable future. Your support through the contribution version helps sustain this tool and others such as the validator that W3C makes freely available to the community — you can also simply donate through our traditional Web interface.

Of course, the cheatsheet is still available as a pure Web application, and both versions will remain in sync — they share most of the code base anyway!

Depending on how successful the app is in the Android Market, I might look into getting it into other similar portals, in particular in stores that distribute W3C Widgets.

I already have a few ideas of possible improvements for both the Web and compiled versions, and very much welcome additional suggestions and feedback.

In my previous blog entry I discussed the five major focus areas for W3C as an organization. They were:

1. Drive a Global and accessible Web
2. Provide a Better Value Proposition for Users
3. Make W3C the best place for new standards work
4. Strengthen our core mission
5. Resource alignment to achieve the first four

In this entry I will elaborate on the third priority.

General background

I motivated this priority in my last post. The Web platform is expanding. There is much new innovation and the Web will benefit if the community brings their work to W3C.

A friction point is that for a variety of reasons it takes time to create standards. Can the pace of standardization keep up with the pace of innovation? A number of factors affect the pace of standards development:

• We are dealing with a mature infrastructure
• The expansion of the platform adds a level of complexity
• Implementation rhythms of software developers are very rapid
• We aim for a royalty-free Web. That is a good thing. But it comes with a side-effect; patent portfolio searches by standards participants. This can take some time.
• More people are involved in the decisions.
• More people and groups are effected by the outcome.
• It takes time to build agreement among stakeholders (in a way that supports fairness and accountability)
• W3C is not set up for large numbers of individual developers (from non-Member organizations) to participate

It is clear to us that to make W3C a more friendly place for New Standards we must recognize these issues and come up with approaches to address them.

Not every problem has an easy solution. The first item in the list — growth of complexity — has shown up in other platforms and is not easy to remove.

Also, W3C's robust process is appreciated by most of our stakeholders. So the challenge is to find solutions that allow the robust process when the community calls for it, and to ensure we also have agile, lightweight processes to meet other community needs. This is the challenge that this team has accepted.

Openness of this effort

If we are to be more agile, more open, attracting different stakeholders, this effort needs to start right now. I've set up a task force with a public wiki where you can follow their progress and learn how to contribute.

In particular, right now the task force is interested in hearing about use cases from the community, such as "we're interested in working together on an ontology in my industry" or "we are a few individuals writing a small format specification and would like to share it with the broader community." The task force invites you to discuss your ideas with them on public-vision-newstd@w3.org (publicly archived). The task force will also be using other means of communication that will soon be listed on their home page.

My recent travels

This imperative — the need to be attractive for new Standards work — was confirmed by my travels over the last two weeks to Belgium, Israel, and the UK. I met with many groups; all different in nature. Each in their own way illustrated the excitement around new technologies and new standards. Here are three examples.

In Brussels I met with officials of the EU. There is attention to the EU's framework program, and making the Web more useful for governments and their citizens through the provision of linked open data. This drives new potential standards.

In Holon, I met with the Garage Geeks, an informal group of innovators working in start-ups for a wide range of technologies. In an hour brainstorming session, it was clear that innovation is moving in its usual disruptive fashion — with the Web as a key platform.

And in Herziliya, I gave a keynote address at an IEEE technical conference. Key themes at this conference included cloud computing, media, smart devices, verticals, and high bandwidth infrastructure. Again, showing innovation going in many different directions.

Do you remember a time when people around you broke out in laughter, but you didn't hear the joke?
You could be doing a similar thing to your audience — leaving some people out. For example, if you say "you can read it on the slide", you're probably excluding people who can't see the slide.

How to Make Presentations Accessible to All is a new WAI resource that helps you make presentations, talks, meetings, and training accessible to all of your potential audience, including people with disabilities and others. It covers planning, preparing slides, providing accessible material, considerations during your session, and more. It also mentions some of the many benefits of inclusive presentations.

WAI would like to know how this resource works for you and how we can improve it. For example, we are considering making the information under the headings expandable and collapsible. You can comment on this blog post or send e-mail to the publicly archived list wai-eo-editors@w3.org (Please share your comments by 19 July 2010 for consideration in the next version.)

Thanks! ~Shawn

How to Make Presentations Accessible to All was developed by Education and Outreach Working Group (EOWG) as part of the training resource suite update with the WAI-AGE Project.

As the first in a series of interviews with SVG implementers for the SVG Working Group blog, I have posted a conversation with Patrick Dengler, the project lead for Microsoft's IE9 SVG team, and a new member of the SVG Working Group.

Read the whole interview on the SVG WG blog.

If you are an implementer of SVG and are interested in doing an interview, please contact Doug Schepers.

The browser vendors have been making great progress on SVG recently, and now it's time for you to make progress in SVG, as well... that is, a progress bar, a spinner, or some other live graphic to indicate that the user has to wait. But you shouldn't wait, because the deadline in June 11.

The deadline for what? For the Web Directions "No Bit, Sherlock!" contest, with prizes so cool they're making me regret agreeing to be a judge rather than an entrant: a laptop tricked out with design software, an XBox 360, LEGO Mindstorms (can haz?), and those building blocks of Maker culture, LEGO and Meccano sets. What are you waiting for? Check out the details, hack up some SVG, and submit your entry.

Through no coincidence at all, I'll be doing a presentation about SVG at the @media conference in London on June 10. I hope to see you there!

The current maintenance update to XHTML Modularization is in response to the inevitable bug reports and clarifications that come from actual use. Since there have recently been some misconceptions expressed about the purpose of the spec, I'd thought I'd take the opportunity to try and clear them up.

XHTML Modularization is a tool for people who design markup languages. It has been used by the people designing the format for Jabber (xmpp), for the open eBook standard (epub), for the microformats specification for outlines (xoxo), and the Resource Directory Description Language (RDDL), among many others, as well as those at W3C such as XHTML 1.1, and RDFa.

Although Rick Jelliffe asserted that XHTML Modularization "...may be one of the most important new technologies of 2001," most people will not be familiar with it. That is because XHTML Modularization is not for designing Web pages, nor is it implemented in browsers: a lot of people create Web pages; not many create new markup languages.

XHTML Modularization helps people design and manage markup language schemas and DTDs; it tells you how to write schemas that will plug together. Modules can be reused and recombined across different languages, which helps keep related languages in sync.

The modularization approach in the spec applies to XML as well. We could have called it "XML Modularization" but the main reason that XHTML appears in the title is that the spec also contains modules for XHTML using the methodology. It is with these modules that XHTML 1.1, XHTML Print, and XHTML Basic (and the others mentioned above) are defined.

Modularization is in some ways an unusual specification for W3C, because you don't have to write any software for it. In a sense, the 'processor' for Modularization is a human who is writing a schema. "Write it following these rules, and it will plug in seamlessly with other modules written in the same way." You could compare it to accessibility guidelines, which just tell you how to construct web pages that are accessible; Modularization just tells you how to write schemas that will plug together. Because it is not a specification to be implemented, it doesn't require the testing that normally ensures the implementability of W3C specifications.