The theme photo for W3C presentations at the TPAC09 showed the Natural Bridges state beach of Santa Cruz, California. We met in Santa Clara (not far from Santa Cruz) 2-6 November in order to bridge various communities and bring them together. For example, bringing together the HTML 5 browser folks and the extensibility folks was a goal. We joked this goal was called "Unnatural Bridges".

Broadening the W3C community was one of the themes of TPAC09, and was reflected in talks as well as participation.

For the first time ever, we invited the public to gather for an afternoon of discussion and networking, the Developer Gathering (the minutes are now available). Ian Jacobs aligned fantastic speakers who regaled us when they presented the latest on various open standards in development. Feedback from the #w3cdev demos included many "very cool", "absolutely amazing", "video element", "impressive", "geolocation", "accelerometer", "APIs", "nice possibilities", "features".

I thought the event went very well and think W3C should organize more. Please let us know what sort of event would appeal to you (e.g., with speakers as we had this time, or more like a bar camp, or a mix). If you blogged about #w3cdev, please, share a pointer in a comment!

TPAC is our biggest yearly event. Each year about 300 people who participate in various W3C groups meet face-to-face to exchange ideas, resolve technology issues, and socialize. My sense is that for most people involved, TPAC is their favorite W3C meeting of the year.

We tracked micro-blogosphere feedback on #tpac09. We expanded the number of people we follow (I'm not yet quite caught up with the additions I wanted to make, so excuse us if we're not yet following you). Likewise, at the occasion of TPAC and the Developer Gathering, a significant number of people also expanded their contact list and started to follow us (yay!). In Santa Clara @dckc said, '@w3c has ~5000 followers'. This is still growing, ~6300 now!

A bit of a mystery to me as I reviewed the tweets is the unicorn meme. I have no idea who started it and why, but unicorns were mentioned, portraited (it even made it to our theme photo!), tweeted, and interjected.

Oh, and I mentioned werewolves in the title. Although not (yet) a resident on our meetings agenda, Werewolves attacked the villagers almost every night at TPAC! Led by fantastic emcee @dontcallmedom, many people enjoyed the battles of minority against majority, the games of suspicion, trust, lies, doubts and beliefs. Nightly werewolf encounters are such fun in person.

If you attended TPAC09 and would like to give feedback, we'd appreciate if you took the WBS survey. I welcome additional feedback, or a pointer to your blog entry in a comment to this entry.

This cheatsheet aims at providing in a very compact and mobile-friendly format a compilation of useful knowledge extracted from W3C specifications — at this time, CSS, HTML, SVG and XPath —, completed by summaries of guidelines developed at W3C, in particular the WCAG2 accessibility guidelines, the Mobile Web Best Practices, and a number of internationalization tips.

Its main feature is a lookup search box, where one can start typing a keyword and get a list of matching properties/elements/attributes/functions in the above-mentioned specifications, and further details on those when selecting the one of interest.

The early feedback received both from TPAC participants after the demo and from the microblogging community has been really positive and makes me optimistic that this tool is filling a useful role.

This is very much a first release, and there are many aspects that will likely need improvements over time, in particular:

• I would like the cheatsheet to cover more content — from specifications not yet released as standards as well as from topics not yet covered (e.g. JavaScript interfaces),
• some people have reported that there might be accessibility problems with the current interface, that I’m eager to fix once I get specific bug reports,
• the cheatsheet doesn’t work in IE6 (and probably even in later versions), and it would be nice to make it work at least somewhat there.

The code behind the cheatsheet is already publicly available, and I’m hoping others will be interested to join me in developing this tool — I’m fully aware that the first thing that will need to get others involved will be some documentation on the architecture and data formats used in the cheatsheet, and I’m thus hoping to work on that in the upcoming few weeks.

In the meantime, I very much welcome bug reports and suggestions for improvements, either by private email to me (dom@w3.org) or preferably to the publicly archived mailing list public-qa-dev@w3.org.

• Leslie Daigle (ISOC) on Internet Ecosystem Health
• Mark Davis (Unicode Consortium) on controversies around international domain names
• Brendan Eich (Mozilla) on "ECMA Harmony and the Future of JavaScript"
• Fantasai on CSS, with help and demos from the "CSS Strike Force": Tab Atkins, David Baron, Simon Fraser, and Sylvain Galineau
• Philippe Le Hégaret (W3C) on community-built browser test suites.
• Kevin Marks (OWF) on OpenID, OAuth, OpenSocial
• Arun Ranganathan (Mozilla) on what's new in APIs

I will be hosting the gathering (5 November in the afternoon). We've planned for some fun give-aways to be revealed at the meeting. Registration closes today, although we will admin walk-ins at a higher rate next week.

If you can't join us in person, you can follow the meeting on IRC; more details are available on the meeting page.

I hope you will join us next week.

• In IE, if you select mobile or print modes, you can't get back to desktop mode.
• In Safari, even if you select "desktop" mode you get mobile mode at narrow browser widths. Also, if you select "mobile" mode you get a mix of mobile and desktop at wider browser window widths.
• In some browsers, you can't expand the expandable content sections; they snap back shut.

We are working on these fixes. I also welcome fix suggestions from the community. Thanks again to those who have sent comments to site-comments@w3.org

Comments are flowing in, some touching on issues we identified when we announced the beta version. Here are a few:

1. Is the CSS invalid? The CSS does not validate with the W3C CSS validator. We mentioned this as one limitation of the site back in March. As we wrote then, "Because of known interoperability issues, we have accepted to use CSS that does not validate with the CSS validator. Over time we hope to evolve towards valid CSS."
2. Why do some pages (such as the graphics introduction, though there are others as well) look unfinished? They are; the generic template text is still there from the beta. We decided to launch the site even without all the content we hope to have. We think the site is a significant improvement over the old one, and so prefer to begin using it rather than wait for more content. The site will continue to evolve, and I hope much more easily. We are asking staff, Working Groups, and the community to help out and provide content. We'd love your help, and are happy to acknowledge your contributions on the pages. Let us know at site-comment@w3.org.
3. Some of the rewritten Recommendations have formatting bugs. Unfortunately, one of our processing passes modified the markup and we didn't realize it; we'll be fixing those problems in place. For the moment we are only using the new templates for Recommendations (old and new). As we gain more experience and resolve formatting issues, we expect to apply the new templates to more publications. One advantage of the new approach will be that it will be easier to tell right up front when a specification has been superseded by another.

There are also a few rendering issues we are aware of and plan to fix over the next few days. Please tell us about any issues you encounter on site-comments@w3.org. Please be sure to tell us the URI of the page in question and what browser and OS you are using.

A group of questions I often get is: how do these two sets of recommendations relate to one another? Did W3C create competing, incompatible technologies that are in the same design space? Why having two? How can they be combined?

To answer this question one has to realize that the two sets of technologies represent different approaches. OWL 2 (and, actually, RDFS) rely, very broadly speaking, on knowledge representation techniques. Think of thesauri, of ontologies, of various classification mechanisms: one classifies and characterizes predicates, resources, and can then deduce logical consequences based on that classification. (On the Semantic Web this usually means discovering new relationships or locating inconsistencies.) RIF, on the other hand, is more reminiscent of logic programming (think of Prolog). Ie, if these and these relationships hold then new relationships can be deduced. (It must be said that RIF also includes a separate work on production rules, but they are fairly distinct from OWL 2, so let us forget about that for the moment.)

Would I want to use OWL 2 or rather RIF to develop an application? Well, it depends. Some applications are better formulated this way, others that way. There are a number of papers published on when one approach is better than the other, how certain tasks can or cannot be expressed using classification or rules, respectively, how reasoning is possible in one circumstances or the other. Very often it also boils down to personal experience and, frankly, taste: some feel more comfortable using rules while others prefer knowledge representation. I do not think it makes sense to claim that one is better than the other. Simply put: they are different and both approaches have their roles to play.

So far so good, the reader could say, but what about using OWL and RIF together?

One of the six recommendation track documents of RIF is called “RIF RDF and OWL Compatibility”. Because we are talking about formal semantics, this document is of course not an easy read. However, in layman's term, what it describes is how the two “sides”, ie, the rule and the classification sides, should work together on the same data set. It defines some sort of an interplay between two different mechanisms: the, shall we say, logic programming part and the knowledge representation part. Implementations doing both are a bit like hybrid cars: they have two parallel engines and a well defined connections between those two. That said, the document only defines what the combination means; whether, for example, engines will always succeed in handling the two worlds together in a finite time is not necessarily guaranteed in all cases. But we can be positive: in many cases (ie, by accepting restrictions here and there) this combination does work well, and there are, actually, good implementations out there that do just that.

A simple case where no problem occurs is the so called OWL 2 RL Profile. This profile has been defined by the OWL Working Group with the goal of being implementable fully via rule engines. This does not necessarily means RIF (I myself have implemented OWL 2 RL by direct programming in Python), but the fact that RIF could also be used is important. The RIF Working Group has therefore published a separate document (“OWL 2 RL in RIF”) which shows just that: it reformulates the rules for the implementation of OWL 2 RL as RIF rules (more exactly, RIF Core rules). Ie, a RIF implementation can just take those rules, import any kind of RDF data that also include OWL 2 statements, and the RIF engine will produce just the right inference results. How cool is that?

So, the answer to the original question is: yes, for many applications, RIF and OWL 2 can happily live together ever after…

• Learning about the Web Content Accessibility Guidelines (WCAG) and either (1) building your own customized checklist for How to Meet WCAG 2.0 or (2) putting together a customized web accessibility business case for your organization;
• Reaching more people by learning about the quick tips for internationalization;
• Cleaning up the Web and showing support for standards by using the W3C validator services;
• Checking to see if your pages are mobileOK.

Happy One Web Day! We'd love to hear your ideas for building One Web.

The result is our first ever Developer Gathering, to be held the afternoon of Thursday, 5 November. The gathering is open to the public though we have in mind in particular the local developers and Web designers who are not the usual participants in W3C work. We are planning a series of speakers to share the latest news about CSS, APIs, some new ideas about browser test suites, and more. The speakers will then take participant feedback back to their groups. Arun Ranganathan (Mozilla), Fantasai, and Philippe Le Hégaret have already confirmed that they will be speaking. We will announce other speakers as they commit. In addition, the HTML Working Group will be meeting at the same time, so lunch, breaks, and the hotel bar will offer more opportunities to network with your colleagues.

The Developer Gathering home has more information about registration (including the $75 registration fee, which covers food, wifi, and other meeting costs). Space is limited to 100 participants, so it's first registered, first served.

We look forward to seeing you in November.

The CSS Working Group was foremost in mind when it comes to testing. The Group has several documents in Candidate Recommendation stage that are waiting tests and testing. The HTML Working Group is starting to look into testing as well and a key component of ensure the proper success of HTML 5 is through testing. The specification is quite big to say the least and, when it comes to testing, it's going to require a lot of work. We also have more and more APIs within the Web Apps group, Device API, Geolocation, etc. The SVG Working Group has a test suite for 1.2, but they're looking at different ways of testing as well. The framework produced by the MWI Test Suites framework allow two methods. One requires a human to look at it and select pass/fail. The other one is more suitable for script tests, ie APIs testing.

A bunch of us, namely Mike Smith, Fantasai, Jonathan Watt, Doug Schepers, and myself, decided to get together to discuss this and figure out how to improve the situation. We focused on three axes: test submissions, test reviews and how to run a test.

First, we'd like ideally every single Web author to be able to submit tests, so when they run into a browser bug based on a specification, it should be easy for them to submit a test to W3C. It should also allow browser vendors to submit thousands of tests at once. There is the question of how much metadata do you require when submitting a test. For example, we do need to know at some point which feature/part of a spec is being tested. We should also as many format as possible for tests. Reftests, mochitests, DOM-only tests, human tests, etc. The importance aspect here is to be able to run those tests on many platforms/browsers as possible. A test format that can only be ran on one browser is of no use for us.

Once a test has been submitted, it needs to be reviewed. The basic idea behind improving test reviews is to allow more individuals to contribute. The resources inside W3C aren't enough to review ten of thousands of tests. We need to involve the community at large by doing crowd reviews. It will allow the working groups to only focus on the controversial tests.

Once the test got reviewed, we need to run them on the browsers, as many as possible. Human tests for example are easy to run on all of them, but it does require a lot of humans. Automatic layout tests are a lot trickier, especially on mobiles. We focused on one method during our gathering: screenshot based approach. The basic idea here is that a screenshot of the page is compared to a reference. Mozilla developed a technology called ref-tests that compares Web pages themselves. You write two pages differently that are supposed the exact same rendering and compare their screenshots. It avoids a lot of cross-platforms issues one can. The way Mozilla is doing that is via the mozPaint API in debug mode. That works well, but only works in Mozilla. You can guess that other browser vendors have a similar to automatically take screenshots as well. We wanted to find a way to do this with all browsers without forcing them or us to write significant amounts of code. We found a Web site called browsertests.org and we got in touch with that Sylvain Pasche and, with his help, we started to make some improvements on his application. It works well on desktops at least. Once again, we don't think W3C is big enough to replicate all types of browser environments, so we should make it easy for people to run the tests in their browser and report the results back to us. Plenty of testing frameworks have been done already and we should try to leverage them as much as possible.

We started to set up a database for receiving the tests and their results. We'd like to continue the efforts on the server/database side, as well as continuing to improve Sylvain's application, allowing more tests methods and formats. Testing the CSS or HTML5 parser should be allowed for example.

You'll find more information at our unstable server but keep in mind that:

1. we're in the very early stages
2. this server is a temporary one that I managed to steal for a few days from our system folks. They'll want it back one of those days and I need to find a more stable home prior to that event. I'll update the link once this happens but expect it to break if you bookmark it.
3. Unless I can secure more resources for the project, we won't go far by ourselves.

The server also contains links to more resources on the Web related to various testing efforts, as well as a more complete of what we wish the testing framework to accomplish.

For the conclusion, I'd like to thank Mike Smith and Doug Schepers, and especially Jonathan Watt and Fantasai from the Mozilla Foundation. They all accepted to argue and code for 8 days around the simple idea of improving the state of testing at W3C. I hope we're going to be able to take this project off the ground in the near future. If you're interested in contributing, got ideas and time, don't hesitate to contact me.

Public companies worldwide are required to file regular reports setting out the financial health of the company. These are available from corporate investor relations websites and from regulatory agencies like the Securities and Exchange Commission (SEC). If you want to analyze this data, you have to re-key it, which involves a lot of work and introduces errors. That is all about to change.

The SEC and kindred agencies around the world are starting to require companies to file reports in XBRL (the extensible business reporting language). XBRL ties each reported item of data to the reporting concept used to collect it, and moreover, does so in a way that computers can make sense of, avoiding the need for re-keying data.

XBRL will allow investor relation sites to support interactive access and sharing of tagged financial data. This will build upon Web 2.0 and the phenomenon of user provided content on wiki's, blogs and social networking sites aimed at investors, e.g. wikinvest, where investors share data, insights and analyses. Youtube provides a powerful precedent in the way it allows people to share content by embedding a view or a link to a view in their blogs.

For XBRL, this means providing a way for people to browse the data, and to pull out tables and charts as needed for their blogs. These items could be rendered by the investor relations site and shared à la Youtube, or the blog could itself make use of a script to query data across one or more investor relations sites and render it locally. This is where the Semantic Web and linked open data comes in. I've previously reported on techniques for converting XBRL into RDF triples.

W3C and XBRL International are looking for your help in understanding what some people are calling "Investor relations 2.0", and we invite you to attend a workshop at the FDIC training facility in Arlington, Virginia, this October. We want your help with identifying the opportunities and challenges for interactive access to business and financial data expressed in XBRL and related languages. This doesn't just apply to the investor community, as the same technologies also offer huge potential for data published by governments on sites like data.gov (see demos). For more details on the workshop see the call for papers.

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

Q.For readers who may not be familiar with NACS Association for Convenience and Petroleum Retailing) , can you describe the role of NACS in one paragraph?

A. Quoting NACS: "NACS serves the convenience and petroleum retailing industry by providing industry knowledge, connections and advocacy to ensure the competitive viability of its members' businesses."

For knowledge, NACS supports member education through meetings such as NACStech (where Tim Berners-Lee has given the keynote on one occasion) and through its printed and on-line publications. For connections, meetings such as the NACS Show and NACStech provide members with the opportunity to meet regularly, and NACS Connect 365 is an online marketplace where NACS Retailer and Supplier members can conduct business.

For advocacy, NACS supports a Government Affairs Program that includes NACSPAC (a political action committee). The short explanation for the role of the Government Affairs Program is to advocate for a business climate that is fair, safe, and equitable for all convenience retailers, large and small. Advocacy also includes the support of standards development and implementation through PCATS, x9, W3C, and the PCI SSC.

The strategic technological direction is guided by the NACS Technology Council, a group of member retailers, technology providers, and CPG companies (i.e. telecom and communications).

Q. Given the current economic climate, what are some of the business challenges faced by NACS members that might be addressed through Web technology?

A. One of the the biggest economic challenges we face is increased interchange fees for use of payment processing networks, as well as the burden of paying for the security infrastructure required to use those networks. Web technologies stand poised to offer better cost alternatives in this area: entrepreneurial companies are already making some inroads on the processing side, and standardization of security protocols and exchange patterns to create a "trusted Web" may provide some relief from the security burden borne today almost solely by retailers.

Q. Can you share any success stories within NACS related to the use of a W3C standard?

A. PCATS (the Petroleum Convenience Alliance for Technology Standards), which is a close ancillary organization to NACS, has produced a standard for in-store EDI (Electronic Data Interchange) ordering. EDI makes it possible to place orders to suppliers (like Coca Cola, Pepsi, or McLane) electronically. The PCATS XML/EDI standard, called EB2B, enables large numbers of small and medium-sized retailers to make use of electronic ordering. Before the Web, this EDI technology was completely out of reach of these merchants. All PCATS standards make use of XML and XML Schema. Note that XML/EDI standards are also available from many other organizations for other retail segments.

Q. How does NACS communicate the value of Web standards to its Membership?

A. The annual NACStech meeting provides NACS members with the ability to hear from industry experts (Tim Berners-Lee and Rod Smith (of IBM) have both been recent keynote speakers) and to attend workshops on technology topics from the mundane (how to train cashiers) to the sublime (what is Web 2.0?). NACS Online also carries frequent articles on applicable technologies.

Q. Are there examples where NACS, through collective advocacy has enabled NACS members to influence the information technology market?

A. Through its Advocacy activity, NACS supports standards development at PCATS and x9, and through those standards produced has changed the landscape for technology products in the convenience and petroleum retailing industry. Before NACS advocacy of these standards, interoperability between store systems was scarce and expensive to develop. We’ve seen a sea change in how technology vendors approach our market as a result of the standards.

Q. NACS has participated in the development of XML Schema 1.1 (which W3C anticipates will become a Recommendation in 2009). For NACS, what are the most important new features in XML Schema 1.1?

A. Two key features are the ability to define co-constraints in the schema and support for the "versioning" of languages. Co-constraints (i.e., the value found in one place in an element can constrain the value allowed in another place in an element) have been used in data serialization technologies (like EDI) for decades: programmers, managers, and merchants understand them and rely on them. These constraints have almost always been implemented in the computer code, and therefore it has been up to the programmer on either end to read the spec carefully and to properly implement the checks on data required: in other words, it’s been very error prone. Allowing the designation of co-constraints in the XML Schema Definition language will be a huge help to those designing new XML languages for retail and for those porting existing retail languages into XML.

Support for versioning means making a given XML language work across processors and versions of those processors, and also to provide the ability to extend existing XML languages easily and intuitively. Deployment of a new language and its required software is a huge cost to any merchant, and support for these versioning strategies will make it possible to save a lot of money and frustration.

Q. Are there other areas of current W3C work of particular importance to NACS (e.g., related to data, voice interaction, ubiquitous Web, geolocation, ...)?

A. The Mobile Web Initiative, along with Device APIs and in-roads into Social Networking standards (I realize that’s a little out of scope) seem to me to have the biggest potential impact on NACS members during the next few years. Of course, the entire planet has a vested interest in the future of (X)HTML(5), but that’s too large a topic for now.

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

A. The W3C provides a unique mix of the ability to work out practical solutions to existing problems (like co-constraints in XML Schema) and to consider the immediate implications of emerging technologies for our industry (like the Semantic Web, Device APIs, "trusted web", and Mobile Web). Being able to be involved in these things simultaneously is to me one of the main strengths of the W3C. Further, once the W3C creates or endorses a technology, it’s much easier for NACS to adopt that technology with the confidence that it’s doing the right thing for its members.

Q. What can W3C do that would most help your organization or the organizations represented in the trade association?

A. The NACS membership has immediate interest in XML technologies, including Web Services (though they are not yet widely deployed), in security related standards ("trusted Web"), and future interest in Semantic Web applications. So, making sure that these business related standards continue to be supported and revised is of great value. NACS would like to see W3C continue to push standards into everyday commerce, enabling further synergy and economies of scale so that we can repeat the "EDI success story" over and over in the future. The Mobile Web Initiative is a good example of the sort of activity NACS finds intriguing, especially as it applies to commerce.

Q. NACS developed an exchange format called NAXML. Can you describe your experience building an industry specific vocabulary on top of core XML standards?

A. The committee I chair at PCATS (the POS Backoffice Committee) was the first to switch to XML for the language of our standard, though I don’t think we finished first (that may have been EB2B). Switching to XML and XML Schema as the basis for our work provided the committee with an unprecedented ability to know we were using the right technology. Before that, we had disagreements about formats (ASN.1, CSV, name-value pairs), and arguments over the substrate consumed a lot of time, thought, and goodwill. Once we adopted XML plus XML Schema as our strategy, these old arguments disappeared and we were able to finish and implement our standard. These implementations were actually portable across various software platforms; we had not been able to achieve that before. And we’ve never looked back.

Many thanks to David for his answers.

What has happened? In January, I was reviewing the algorithms section in XML Signature while working on the XML Security Working Group's Algorithms Cross-Reference draft. I read a certain paragraph. I read it twice. I grabbed a copy of the nearest open source implementation of the spec that I could find. I read some code. I built an example to play with. And then, I took up the phone. A week later, we spent some time on a Working Group call to talk things through, followed by a series of informal conference calls to understand how serious the problem was, and what to do when. Half a year later, a number of vendors are pushing patches to fix their versions of the hypothetical problem I had stumbled over.

Here is the text that struck me:

The HMAC algorithm (RFC2104...) takes the truncation length in bits as a parameter; if the parameter is not specified then all the bits of the hash are output. An example of an HMAC SignatureMethod element:

   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
      <HMACOutputLength>128</HMACOutputLength>
   </SignatureMethod>

The output of the HMAC algorithm is ultimately the output (possibly truncated) of the chosen digest algorithm. This value shall be base64 encoded in the same straightforward fashion as the output of the digest algorithms.

Conventional wisdom is that you don't lose much in terms of security if you throw away up to half of the output. And that's where it gets interesting: XML Signature provides markup to send the truncation length along with the signature. But it doesn't say who has to worry about checking the truncation length.

Imagine Alice and Bob agree on a secret, and imagine that Alice will accept that a message comes from Bob if it's signed with an HMAC using that secret. They use XML Signature to encode the signatures. Enter Mallory: She doesn't know the secret, but she has a message that she wants to send to Alice, claiming that it comes from Bob. Guessing the right HMAC value is basically impossible when the output of the HMAC function is a string of 160 bits. But what if Mallory could convince Alice to throw away 152 of the 160 bits? Suddenly, she has a chance of 1 in 256 of guessing the right signature value. Or what if Mallory could convince Alice to throw away all of the 160 bits? There's only one signature value that's possible, regardless of the message and the key. Now, if Alice has a careful look at the messages she receives, she will surely notice when Mallory's message tells her to throw most of the signature away.

But what if Alice doesn't look?

That's precisely what has happened here: A naive implementation of XML Signature simply accepts an HMAC-based signature, including the truncation length parameter, looks at the number of bits it's been told to look at, and reports back whether the signature was good or bad. It doesn't do any other check of the output length, or report it back, or ask the calling code for a minimum (while, perhaps, setting a sane default).

Now, strictly speaking, the specification isn't even wrong. It does, however, leave a critical decision to "somebody else", without saying so. It turns out that the HMAC specification itself warns about too short output lengths -- and, indeed, we know of one implementation that got this right from the beginning. Others had simply not cared to implement this particular feature. But many (see the CERT vulnerability note for details) had implemented the feature, and then forgotten about it -- from all we know, the output length parameter is hardly, if ever, used with XML Signature.

Likewise, some specifications that refer to XML Signature come close to dealing with the issue, but ultimately don't: The WS-I basic security profile forbids sending the truncation length parameter -- but it doesn't keep implementations from accepting it. WS-SecurityPolicy has information about minimum key lengths for HMACs -- but none about minimum output lengths.

If there is a security critical parameter in a specification, then, at the very least, that needs to be said clearly and loudly. In this case, we're going one step further: The proposed correction that was published today adopts the limits recommended by RFC 2104 and tells implementers to consider signatures as invalid whose truncation length falls below these limits.

Why did it take half a year?

Releases across a possibly significant number of vendors had to be coordinated. Today was the earliest date everyone could agree on. At the same time, it didn't look like services exposed to the Internet would be adversely affected by the delay.

A number of people helped with dealing with this situation: Hal Lockhart was instrumental in helping to understand the implications in the Web Services space. Frederick Hirsch made time available during XML Security Working Group calls. Will Dormann at CERT helped to coordinate vendor responses during the last few weeks.

How do I know if my software is affected?

Probably not. It turns out that the affected feature in XML Signature is used less frequently than we had at first thought. If you use Web Services in a way that relies on the HMAC feature in XML Signature, then you might want to make sure that you're using the latest release of your toolkit. The same holds if you've built your own protocols and toolkits on top of XML Signature. See the CERT vulnerability note for details. (Please understand that we won't discuss individual implementations here.)

Does this affect other protocols?

We are not aware of any.

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.