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.

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.

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

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.

I do mistakes very often. English is not my mother tongue. I try to fix spelling mistakes as much as possible. Still, my English grammar is still behind. Oh, not looking for any excuses, I do mistakes in French too. But I'm glad that our brains have a very robust parsing mechanism which helps us to recover from broken sentences (bad spelling and clumsy grammar). Just imagine for the experiment, that your brain was not able to parse any sentences that would not be grammatically correct. How many sentences in our daily conversation are 100% correct? Not that much.

At W3C, we take meetings minutes (a lot) of discussions happening over a phone. During these teleconferences, there are people from different nationalities, different accents, different levels of English and on top of that in different time zones (fatigue). Still the scribe (minute taker) writes down, most of the time, correct English sentences after parsing them. The scribe creates a serialization of what he heard, but modifies it to be correct.

An HTML 5 Tidy library could do the same thing. It could parse a broken document and create a DOM following the HTML 5 parsing algorithm. Then it could serialize it (writes it down) following the HTML 5 content model. That would create a conformant HTML 5 document.

This is an important part of the process. What you hear is not what you write. You are stricter, once you have recovered the meaning. The same way what the HTML 5 Tidy library has parsed is not what it will serialize. Let's take a practical example with the infamous center element.

<!DOCTYPE html>
<html>
  <title>a broken document</title>
  <center><p>I want to be in the center of the page.</p></center>
</html>

The innerHTML view (using HTML 5 Live DOM viewer) is:

<!DOCTYPE HTML>
<html>
  <head>
    <title>a broken document</title>
  </head>
  <body>
    <center><p>I want to be in the center of the page.</p></center>
  </body>
</html>

But the document will be invalid and the message given by the experimental HTML 5 validator instance will be

Validation Output:  1 Error
#  Error  Line 4, Column 7: The center element is obsolete..

Why? Because nowhere in the content model of HTML 5, the center element is defined. You can't write an HTML 5 conformant document containing the center element. An HTML 5 Tidy library would emit only elements which are compatible with the HTML 5 content model. In this case that could be

<!DOCTYPE HTML>
<html>
  <head>
    <title>a broken document</title>
  </head>
  <body>
    <p>I want to be in the center of the page.</p>
  </body>
</html>

Some people will argue that everyone will want different rules. Indeed that is possible. Some will want to have double quotes around attributes, some single quotes. And if we take into account the set of documents which have complex mixed markup, it will indeed create a lot of headaches. But it's why I think it would be interesting to define a set of basic rules for emitting HTML 5 after it has been parsed.

Some might propose solutions of the following type for the center element.

<!DOCTYPE HTML>
<html>
  <head>
    <title>a broken document</title>
  </head>
  <body>
    <p style="text-align:center;">
      I want to be in the center of the page.
    </p>
  </body>
</html>

Daniel Glazman proposed recently something quite similar for HTML attributes, inline style or style rules.

Are there any engineers which would be ready to take the challenges of designing an HTML 5 Tidy Library (and the canonic rules to fix the output) using the content model of HTML 5? I showed recently that there will be less document validating with the HTML 5 doctype than with their current doctype. Henri Sivonen rightly commented that HTML 5 content model was stricter than previous versions of HTML. This will not leverage the adoption of conformant HTML 5.

An HTML 5 Tidy Library (even not perfect) would help people to move forward. If there are no benefits, people will continue to use HTML 4.01 and/or XHTML 1.0 because, in the end it doesn't matter,

• it will still be parsed correctly by browsers.
• Authors can use the existing XHTML books out there, rely on their years of experience of the language and business practices,
• and, last but not least, they will benefit of the tools which fix their invalid content.

• GRDDL implementations add support for rel="profile" along with HTML 5 concrete syntax.
• GRDDL implementors don't change their code, so people who want to use GRDDL with HTML 5 features such as <video> stick to XML-wf-happy HTML 5 syntax and they use the head/@profile attribute anyway, despite what the HTML 5 spec says.
• People who want to use GRDDL stick to XHTML 1.x.
• People who want to put data in their HTML documents use RDFa.

I don't particularly care for the rel="profile" design, but one should choose ones battles and I'm not inclined to choose this one. I'm content for the market to choose.

Emails have basic metadata (author, subject, date), which helps to create proper indexing and search. It could be certainly refined with sophisticated search algorithms. Digital photos have now EXIF (including date, and technical parameters of the camera) but nothing much else. My brain associates these photos ordered in a dated space with a list that I maintain of my very rough location. It helps me remember in which city it was taken, but nothing more.

Here lies the challenge. Giving more precise metadata to these photographs would be certainly useful for my own consumption but … a fulltime job. That would make me a digital Stakhanovite.

In Musings on photographic metadata, Sean McGrath says:

A great tragedy lies herein. A sad law of this universe seeps forth like an Einstinien nightmare. A law that goes something like this : "the chances of any normal human being taking the time to add incredibly valuable meta-data to the great wads of digital data they create daily, approximates zero." An alternative formulation - using the classic dentistry analogy goes like this: "Most people would prefer root canal work than the utter tedium and ambient feeling of futility that accompanies meta-data creation. Besides everyone is too busy. Oh, and besides that again, it always seems to be more fun to create new stuff than to create stuff about old stuff."

Sean is trying to see what could be done automatically through the devices, location is certainly one that should happen more and more often, see the new Nikon Coolpix P6000 with GPS and the geolocation activity creation being discussed at W3C right now.

The challenges become bigger when you want to share these photos with a larger public. At regular cycle, there is a rage debate over alt attribute on html working group mailing list. I'm not sure there is a perfect solution and we have to find a way to accomodate the circumstances of this sharing. The difficulty is that the right solution is more social than technical. Giving meaningful alternative information for the images you put online, really depends on the context. These are real scenarios.

1. You want to share photos with your family. You sent them by emails (HTML emails most of the time), or you create an html gallery which is made by a software and put them online. You usually don't put more information than giving the context of the event and maybe sometimes description of some particular outstanding image, such as "Hey see the image below, it is the beach just in front of our room." The value of the image is limited to a few persons you know, still it might be here for public consumption.
2. You are writing an article on the Web about graphics arts. The article has a lot of illustrations which are part of the argumentation, demonstrations. There are not only visual references, there are elements of the discourse.
3. You are writing an online diary mixing images, quotes, and different impressions. Your site is more like a scrapbooking exercise. Images are often here to give a mood of your writings. There are like simple touches of colors, or even sometimes an element of phrase. They have more emotional values for the readers who can see than anything else.

There are many more possible cases. The big issue is how do we design the technology so that it will accomodate a maximum of use cases (social contexts) without making impossible for others to exist. There is not yet a definitive answer.

As it turns out, our friends in Switzerland will only start recreating the time just after the big bang in a month. Ah well. Until then, we will have time to enjoy sports on TV, and the Markup Validator, release 0.8.3.

This is mostly a maintenance release, fixing a few bugs, adding support for recently added or updated document types such as XHTML Basic 1.1, but it does have a number of valuable tricks up its sleeves.

For those of us using the validator not just as a web service but as a web platform, a couple of new features will make our life even easier. First, a json output has been added to the validator's results possible outputs. The format is modeled after the JSON output built by our friends at validator.nu. Try this:

GET "http://validator.w3.org/check?uri=http://qa-dev.w3.org/wmvs/HEAD/dev/tests/2342-opensp_type_X.html&output=json"

…you get:

{
    "url": "http://qa-dev.w3.org/wmvs/HEAD/dev/tests/2342-opensp_type_X.html",
    "messages": [
        
          {
              
              "type": "info",
              "subtype": "warning"
              "lastLine": "11",
              "lastColumn": 20,
              "message": "reference to non-existent ID \"MMIARCH\"",
              "messageid": 183,
              "explanation": "    
        [...]
    <div class=\"ve mid-183\">        
    <p>This error can be triggered by:</p>        
    <ul>        
      <li>A non-existent input, select or textarea element</li>        
      <li>A missing id attribute</li>        
      <li>A typographical error in the id attribute</li>        
    </ul>        
    <p>Try to check the spelling and case of the id you are referring to.</p>        
  </div>        
",
          }
        
        ],
    "source": {
        "encoding": "utf-8"
    }
}

While we are looking at calling the validator and getting quick, easy to process results, did you know that the fastest way to get basic info on validation were the validator's custom HTTP headers? They have been around for a while, now are properly documented and we have added information about the number of warnings, too. Try this:

HEAD http://validator.w3.org/check?uri=http://qa-dev.w3.org/wmvs/HEAD/dev/tests/2342-opensp_type_X.html

    200 OK
    Date: Fri, 08 Aug 2008 15:00:49 GMT
    Content-Language: en
    Content-Type: text/html; charset=utf-8
    Client-Date: Fri, 08 Aug 2008 15:00:52 GMT
    Client-Peer: 128.30.52.49:80
    Client-Response-Num: 1
    X-W3C-Validator-Errors: 0
    X-W3C-Validator-Recursion: 1
    X-W3C-Validator-Status: Valid
    X-W3C-Validator-Warnings: 1

Another good piece of news. If you have a vested interest in XHTML, you will know this dilemma fairly well:

• XHTML is supposed to be served with the media type application/xhtml+xml media type. That XHTML media type has a few issues, however, in particular the fact that the most distributed browser, up to now, still hasn't added support for it.
• XHTML 1.0 defined an informative way to be “served as (legacy) HTML”, which kind of worked. But for the rest of the XHTML family…? Some people came up with clever hacks, using HTTP format negotiation to serve XHTML as application/xhtml+xml only to the agents that clearly specify they support this media type, and as text/html, by default, to the others
• What does that have to do with the Markup Validator? It does not declare an authoritative list of the media types it accepts. Actually, it can't, since there is no way in HTTP to say "Accept HTML, SVG, MathML… and any kind of XML". It does not have to, either, since the HTTP technology makes the Accept header optional, and its absence just means “send me what you've got”
• When checking one resource set up with the Accept hack for XHTML, the validator would be served content as text/html, and, since that is not supposed to happen, the validator would yield a warning stating, in essence are you certain you really want to serve XHTML 1.1 content as text/html?.

It may have been a mere warning, but it made a lot, lot, lot of people anxious and upset. So, by popular demand – and also because the XHTML working group are preparing a revised note on XHTML and media types −　the warning is gone.

Those interested in HTTP content negotiation beyond the issue with XHTML media type will be interested with some new features in the validator. In version 0.8.2 we had added a way to specify the Accept: and Accept-Language headers sent by the validator to the server holding documents it checks, and in 0.8.3 we also added Accept-Charset and User-Agent. These options are still experimental, but should be useful for content-negotiated resources that do not have a specific URI for each representation.

There is more in this version, and more to come. Read the 0.8.3 release notes, learn how to send feedback or participate in the project, and join me in thanking everyone involved in this release.