war-of-the-worlds.html 27.8 KB

Raw Blame History Permalink

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <style type="text/css" media="all">
    @import "/QA/2006/01/blogstyle.css";
    </style>
    <meta name="keywords" content='html5, javascript, microformats, rdfa, semantic web' />
    <meta name="description" content="Some people are amazing, they are creators. They make complex things, beautiful and simple. They make the world a place of exploration and discovering." />
    <meta name="revision" content="$Id: war-of-the-worlds.html,v 1.45 2011/12/16 03:02:54 gerald Exp $" />
   <link rel="alternate" type="application/atom+xml" title="Atom" href="http://www.w3.org/QA/atom.xml" />
   <link rel="alternate" type="application/rss+xml" title="RSS 1.0" href="http://www.w3.org/QA/news.rss" />
   <title>The War of the Worlds - W3C Blog</title>

   <link rel="start" href="http://www.w3.org/QA/" title="Home" />
   <link rel="prev" href="http://www.w3.org/QA/2008/06/shipbuilding.html" title="Shipbuilding (or, cruel to be kind)" />
   <link rel="next" href="http://www.w3.org/QA/2008/06/what_benevolent_dictator.html" title="What Benevolent Dictator?" />

   <!--
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description
    rdf:about="http://www.w3.org/QA/2008/06/war-of-the-worlds.html"
    trackback:ping="http://www.w3.org/QA/sununga/mt-tb.cgi/190"
    dc:title="The War of the Worlds"
    dc:identifier="http://www.w3.org/QA/2008/06/war-of-the-worlds.html"
    dc:subject="HTML"
    dc:description="Some people are amazing, they are creators. They make complex things, beautiful and simple. They make the world a place of exploration and discovering."
    dc:creator="Karl Dubost"
    dc:date="2008-06-27T07:27:43+00:00" />
</rdf:RDF>
-->

    <!-- <script type="text/javascript" src="http://www.w3.org/QA/mt.js"></script>-->

</head>
<body class="layout-one-column">
      <div id="banner">
      <h1 id="title">
	<a href="http://www.w3.org/"><img height="48" alt="W3C" id="logo" src="http://www.w3.org/Icons/WWW/w3c_home_nb" /></a>
W3C Blog
</h1>
    </div>

    <ul class="navbar" id="menu">
        <li><strong><a href="/QA/" title="W3C Blog Home">[ W3C Blog ]</a></strong></li>
        <li><a href="/QA/Library/" title="Documents and Publications on Web and Quality">Documents</a></li>
        <li><a href="/QA/Tools/" accesskey="3" title="Validators and other Tools">Tools</a></li>
        <li><a href="/2007/12/qa-blog-help/index#feedback">Feedback</a></li>
    </ul>
<div id="searchbox">
<form method="get" action="http://www.google.com/custom" enctype="application/x-www-form-urlencoded">
<p id="formbox"><input type="text" size="15" class="textfield" name="q" accesskey="E" maxlength="255" /> <input type="submit" class="submitfield" value="Search" id="goButton" name="sa" accesskey="G" /> <input type="hidden" name="cof" value="T:black;LW:72;ALC:#ff3300;L:http://www.w3.org/Icons/w3c_home;LC:#000099;LH:48;BGC:white;AH:left;VLC:#660066;GL:0;AWFID:0b9847e42caf283e;" /><input type="hidden" id="searchW3C" name="sitesearch" checked="checked" value="www.w3.org/QA" /><input type="hidden" name="domains" value="www.w3.org/QA" /></p>
</form>
</div>


    <div id="main"><!-- This DIV encapsulates everything in this page - necessary for the positioning -->

                     <p class="content-nav">
                        <a href="http://www.w3.org/QA/2008/06/shipbuilding.html">&laquo; Shipbuilding (or, cruel to be kind)</a> |
                        <a href="http://www.w3.org/QA/">Main</a>
                        | <a href="http://www.w3.org/QA/2008/06/what_benevolent_dictator.html">What Benevolent Dictator? &raquo;</a>
                     </p>

                        <h2 class="entry-header">The War of the Worlds</h2>
                           <div class="entry-body">
                              <p>Almost 70 years ago, on a Sunday, October 30, 1938, we could <a href="http://en.wikipedia.org/wiki/The_War_of_the_Worlds_%28radio%29">hear on a radio</a>:</p>

<blockquote>
  <p>Ladies and gentlemen, we interrupt our program of dance music to bring you a special bulletin from the Intercontinental Radio News. At twenty minutes before eight, central time, Professor Farrell of the Mount Jennings Observatory, Chicago, Illinois, reports observing several explosions of incandescent gas, occurring at regular intervals on the planet Mars.</p>
</blockquote>

<p>Recently on Monday, June 23, 2008, we could <a href="http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml">read on a radio site</a></p>

<blockquote>
  <p>hCalendar will be gone from /programmes by the next deploy (probably this Thursday).</p>

  <p>In the meantime we'll be looking at the possible use of RDFa (a slightly bigger S semantic web technology similar to microformats but without some of the more unexpected side-effects).</p>
</blockquote>

<p>What's common between the two? They created a big wave of <a href="http://ejohn.org/blog/bbc-removing-microformat-support/" title="John Resig -   BBC Removing Microformat Support">reactions</a>, <a href="http://times.usefulinc.com/2008/06/24-uf-rdfa" title="The BBC, microformats, RDFa and Resig">comments</a> and <a href="http://www.bloglines.com/search?q=bcite%3A%22http%3A%2F%2Fwww.bbc.co.uk%2Fblogs%2Fradiolabs%2F2008%2F06%2Fremoving_microformats_from_bbc.shtml%22+lang%3Aany&amp;ql=en&amp;s=f&amp;pop=n&amp;news=n" title="Bloglines | Search: bcite:&quot;http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml&quot; lang:any">arguments</a>: A war of the worlds. </p>

<h2>microformats, RDFa and HTML 5</h2>

<p>I would like to focus on two blog posts which I like in this flood of comments. There are many more interesting.</p>

<p>Ed Dumbill says in <a href="http://times.usefulinc.com/2008/06/24-uf-rdfa">The BBC, microformats, RDFa and Resig</a>:</p>

<blockquote>
  <p>One of the wonderful things <a href="http://ejohn.org/blog/" title="John Resig">Resig</a> has done with JavaScript is take time to love it and figure out its corners. Take some of the "confusing" and "advanced" things away and you're not able to achieve the same things. What he's done in jQuery is add a layer of elegance, predictability and accessibility.</p>

  <p>I for one would love to see what Resig would do with semantic markup. jQuery really encourages and enables good markup practices, so there's a lot of synergy with his current style.</p>
</blockquote>

<p>Not only jQuery, I met once, John Resig in Tokyo. He was giving a talk about new features of the future Ecmascript. It was complex, not necessary easy to understand, but he made it in a way that was enlightning. We could see he had pleasure talking about it. That was refreshing. I decided to put it on the side of good speakers who are worth to go see again.</p>

<p>Then not so far ago, John ported <a href="http://ejohn.org/blog/processingjs/" title="John Resig -   Processing.js">Processing vizualization language</a> to Javascript. I love graphics and information processing. It was yet again another moment of pleasure thinking "Some people have talents and creativity in their hands, they do beautiful things with complex objects."</p>

<p>The other blog post is in French and <a href="http://www.cynicalturtle.net/kame/index.php/2008/06/24/400-le-site-web-de-la-bbc-abandonne-hcalendar-dans-sa-partie-programmes-tv" title="Le site web de la BBC abandonne hCalendar dans sa partie programmes TV - La Tortue Cynique / The Cynical Turtle">comment</a> also about the affair. Damien Bonvillain is giving his take on RDFa and its <strong>simplicity</strong>:</p>

<blockquote>
  <p>In fact, RDFa defines only 5 new attributes (about, property, resource, datatype, typeof)</p>
</blockquote>

<p>RDFa became a <a href="http://www.w3.org/TR/2008/CR-rdfa-syntax-20080620/" title="RDFa in XHTML: Syntax and Processing">candidate recommendation</a> last week. You can read the <a href="http://www.w3.org/TR/xhtml-rdfa-primer/" title="RDFa Primer">Primer</a> or go to the <a href="http://rdfa.info/wiki/RDFa_Wiki" title="RDFa Wiki - RDFaWiki">RDFa wiki</a> to learn a bit more about the technology. Yes, indeed, for some people it will need a bit of work to understand the concepts. But it took me time to learn HTML, and I don't really master Javascript, but people like John gave me the opportunity to simplify things by developping tools, libraries or authoring tools.</p>

<p>And HTML 5 in all that? Here again there is the story behind the story. The first version of RDFa was using a lot elements like <code>meta</code> and <code>link</code> in the <code>body</code> of a page. But browsers because of invalid markup found on the Web have to recover pages and put back the <code>link</code> and the <code>meta</code> in the <code>head</code> of the document. <strong>RDFa community listened</strong> and learned. They modified their model to make a step toward HTML 5, to create an environment that will create less interoperability issues. They made a step in the right direction to be able to work together. </p>

<p>Next week, I will show why it is important and how that can work even if not perfectly. But remember, it is because there are people like John Resig, who creates, that complex things become easy. The war of the worlds was a fiction.</p>

                           </div>
                           <div id="more" class="entry-more">


                           </div>
                       <p class="postinfo">Filed by <a href="http://www.w3.org/People/karl/">Karl Dubost</a> on June 27, 2008  7:27 AM in <a href="http://www.w3.org/QA/archive/technology/html/">HTML</a>, <a href="http://www.w3.org/QA/archive/web_spotting/opinions_editorial/">Opinions &amp;amp; Editorial</a>, <a href="http://www.w3.org/QA/archive/technology/semantic_web/">Semantic Web</a>, <a href="http://www.w3.org/QA/archive/w3cqa_news/w3c_life/">W3C Life</a><br />
<span class="separator">|</span> <a class="permalink" href="http://www.w3.org/QA/2008/06/war-of-the-worlds.html">Permalink</a>
                                 | <a href="http://www.w3.org/QA/2008/06/war-of-the-worlds.html#comments">Comments (4)</a>
                                 | <a href="http://www.w3.org/QA/2008/06/war-of-the-worlds.html#trackback">TrackBacks (0)</a>
</p>


<h3 class="comments-header" id="comments">Comments</h3>
<div class="comment" id="comment-151234">
<p class="comment-meta" id="c151234">
<span class="comment-meta-author"><strong>Henri Sivonen </strong></span>
<span class="comment-meta-date"><a href="#c151234">#</a> 2008-06-27</span>
</p>
<div class="comment-bulk">
<p>I think counting only 5 attributes as simplicity misses the main point of complexity: RDFa uses QNames in content (considered an anti-pattern by many—including me) and to resolve them, you need to know the namespace mapping context at each node.</p>

<p>It's not only an issue of HTML not having a concept of namespace mapping context traditionally or in HTML5 as drafted. While tracking the namespace mapping context on the application-level is feasible when the document tree doesn't change (e.g. when you compile an XSLT program), keeping track of the namespace mapping context becomes problematic in a browser environment where scripts can mutate the document tree over time.</p>

<p>For the problem at hand, HTML5 proposes the 'time' element as the solution. Unfortunately, the 'time' element is not part of HTML 4.01 and is, therefore, against microformat principles. But then, RDFa attributes weren't in HTML 4.01, either.</p>

</div>
</div>


<div class="comment" id="comment-151388">
<p class="comment-meta" id="c151388">
<span class="comment-meta-author"><strong>Damien B </strong></span>
<span class="comment-meta-date"><a href="#c151388">#</a> 2008-06-28</span>
</p>
<div class="comment-bulk">
<p>Henri, the count of 5 attributes was only a reaction to the statement made by John Resig that RDFa introduced "many new attributes", and citing 3 of them, giving the image that it was a small part of the overwhelming number of new attributes.</p>

<p>"keeping track of the namespace mapping context becomes problematic in a browser environment where scripts can mutate the document tree over time."</p>

<p>The mutating tree problem is disconnected from the namespace mapping context problem. Right now, if you want to take that in account, you can throw away maybe 95% of the existing microformat parsers. The temporal model for interpreting inner metadata (µformat, RDFa, whatever...) is currently undefined. For instance, the Tails Export extension on Firefox is not refreshed automatically on tree mutation, and it doesn't support the "include pattern" mandated by hReview. The Operator Firefox extension does not seem to support hReview or hResume at all, so it's difficult to know how it would handle the "include pattern" in the case of a tree modification (other modifications are reflected on-the-fly).</p>

<p>My point is: so far, when there is scripting manipulation of the DOM, there are already problems for the existing in-browser microformat interpreters. As such, we can read in "RDFa in XHTML: Syntax and Processing" §5.5 : "In other words, XHTML processing rules must still be applied, even if document processing takes place in a non-HTML environment such as a search indexer.", which shows that those kind of metadata must be usable without client-side scripting support (which does not mean that we should not have that kind of metadata targeted to a browser environment).</p>

<p>Now, how is the handling of the namespace mapping context on a mutating tree hard? It basically is a cascading problem, and DOM3 appendix B is frozen since more than four years ago.
You say in the pamphlet "namespaces considered harmful": "I wonder how many hours in my life has been wasted looking up namespace URIs for copying and pasting". I wonder how many hours of my life has been wasted looking up from where my CSS styles were coming from and why the selectors didn't work as I expected. Meanwhile, I didn't contribute any line to a text named "C in CSS considered harmful". I don't see how people writing CSS handling code could fail to tackle the namespace mapping problem, it is just beyond me.</p>

<p>"For the problem at hand [...]. But then, RDFa attributes weren't in HTML 4.01, either."</p>

<p>So it's fine, because the pages at hand, BBC/programmes, are not HTML 4.01. They are not XHTML 1.1 either, but a switch from XHTML 1.0 strict to it is not a huge step. But then again, the problems are: can I represent my metadata? is it accessible? The microformat's way for the problem at hand is not accessible. Is the "time" element a solution, even as a hack? It could be, but by violating every known microformat parser implementation, it's kind of defeating the purpose. Furthermore, it would put the constraint on having a mandatory "datetime" attribute on the time element, since we can not expect microformat parsers to talk to the DOM (maybe it's so in HTML5?).</p>

</div>
</div>


<div class="comment" id="comment-151791">
<p class="comment-meta" id="c151791">
<span class="comment-meta-author"><strong>Henri Sivonen </strong></span>
<span class="comment-meta-date"><a href="#c151791">#</a> 2008-06-30</span>
</p>
<div class="comment-bulk">
<blockquote>
  <p>The mutating tree problem is disconnected from the namespace mapping context problem. </p>
</blockquote>

<p>They are interrelated in a browser context.</p>

<blockquote>
  <p>Right now, if you want to take that in account, you can throw away maybe 95% of the existing microformat parsers. </p>
</blockquote>

<p>Obviously, the tree mutation case is not applicable to microformat parsers that don't run inside a browser and don't have another means of executing scripts.</p>

<p>That the problem is inapplicable to RDFa consumers outside the browser is not the point. The point is that microformats and a metaformat positioned as a microformat replacement should work robustly inside a browser as well.</p>

<blockquote>
  <p>The temporal model for interpreting inner metadata (µformat, RDFa, whatever...) is currently undefined. </p>
</blockquote>

<p>That's bad. (As far as undefined things go, the main issue I take with microformats is that the microformats community doesn't provide a document conformance spec and a processing spec on the HTML5 level of detail.)</p>

<blockquote>
  <p>For instance, the Tails Export extension on Firefox is not refreshed automatically on tree mutation, </p>
</blockquote>

<p>That seems inconvenient especially for microformats that are particularly suited for in-browser consumption and applicable to ajaxy use cases, such as hCard and hCalendar that one would want to be UI-sensitive for transferring into an address book or calendar app.</p>

<blockquote>
  <p>and it doesn't support the "include pattern" mandated by hReview. The Operator Firefox extension does not seem to support hReview or hResume at all, so it's difficult to know how it would handle the "include pattern" in the case of a tree modification (other modifications are reflected on-the-fly).</p>
</blockquote>

<p>hReview and hResume don't make as much sense for in-browser support as hCard and hCalendar. hReview and hResume target content aggregators.</p>

<blockquote>
  <p>My point is: so far, when there is scripting manipulation of the DOM, there are already problems for the existing in-browser microformat interpreters.</p>
</blockquote>

<p>If script manipulation is already a problem, does it make sense to make the problem worse?</p>

<blockquote>
  <p>Now, how is the handling of the namespace mapping context on a mutating tree hard? It basically is a cascading problem, and DOM3 appendix B is frozen since more than four years ago. </p>
</blockquote>

<p>That more code than no code. And what benefit do you get from the layer of indirection that Namespaces is at the end of the day?</p>

<blockquote>
  <p>You say in the pamphlet "namespaces considered harmful": "I wonder how many hours in my life has been wasted looking up namespace URIs for copying and pasting". </p>
</blockquote>

<p>I wasn't aware that I was being quoted on the microformats wiki. Thanks for letting me know.</p>

<blockquote>
  <p>I wonder how many hours of my life has been wasted looking up from where my CSS styles were coming from and why the selectors didn't work as I expected. Meanwhile, I didn't contribute any line to a text named "C in CSS considered harmful". I don't see how people writing CSS handling code could fail to tackle the namespace mapping problem, it is just beyond me.</p>
</blockquote>

<p>Because the CSS cascade provides more value than the indirection Namespaces provide? Also, the people who implement the CSS cascade and the people who implement metadata scaping are not the same people.</p>

<p>Furthermore, citing another case where values propagate in the tree (CSS, xml:lang, base URI, etc.) doesn't make QNames in content less brittle in the face of DOM manipulation. </p>

<blockquote>
  <p>"For the problem at hand [...]. But then, RDFa attributes weren't in HTML 4.01, either."</p>

  <p>So it's fine, because the pages at hand, BBC/programmes, are not HTML 4.01. They are not XHTML 1.1 either, but a switch from XHTML 1.0 strict to it is not a huge step. </p>
</blockquote>

<p>HTML 4.01 vs. XHTML 1.0 vs. XHTML 1.1 is irrelevant as far as the validation point goes. Neither HTML5 'time' nor RDFa is valid in any of them.</p>

<blockquote>
  <p>It could be, but by violating every known microformat parser implementation, it's kind of defeating the purpose. </p>
</blockquote>

<p>If you want to use something other than the abbr design pattern and you want the result to work with existing software that only works with the abbr design pattern, there's nowhere you can go. (RDFa doesn't work with every existing microformat parser, either.)</p>

<blockquote>
  <p>Furthermore, it would put the constraint on having a mandatory "datetime" attribute on the time element, since we can not expect microformat parsers to talk to the DOM (maybe it's so in HTML5?).</p>
</blockquote>

<p>I don't follow.</p>

</div>
</div>


<div class="comment" id="comment-152801">
<p class="comment-meta" id="c152801">
<span class="comment-meta-author"><strong>Damien B </strong></span>
<span class="comment-meta-date"><a href="#c152801">#</a> 2008-07-04</span>
</p>
<div class="comment-bulk">
<p>Sorry for the late answer...</p>

<p>For the sake of concision, I will name "in-browser" the use case where the metadata interpreter is executed inside a web browser, and supposed to be written in javascript talking to the DOM; "standalone" is the use case where the metadata interpreter does not use a web browser environnement and especially, does its own parsing of the document and does not interpret the script elements.</p>

<blockquote>
  <blockquote>
    <p>The mutating tree problem is disconnected from the namespace mapping context problem.
    They are interrelated in a browser context.</p>
  </blockquote>
</blockquote>

<p>Basically everything it interrelated in a browser context. But for "standalone", it has no meaning. And for "in-browser", namespace mapping does not raise specific problems with relation to mutating tree: algorithms exist already. </p>

<blockquote>
  <p>The point is that microformats and a metaformat positioned as a microformat replacement should work robustly inside a browser as well.</p>
</blockquote>

<p>From a strict robustness point of view, I don't see how a XML namespace based solution is less robust than a "magical CSS class name" based solution. Now, current web browsers are indeed poor fits for anything labelled "robust" at that time regarding standards, and especially the XML related ones.</p>

<blockquote>
  <p>hReview and hResume don't make as much sense for in-browser support as hCard and hCalendar. hReview and hResume target content aggregators.</p>
</blockquote>

<p>A microformat should work robustly inside a browser as well. hCard and hCalendar make sense in "in-browser" today because there are standard standalone formats to represent them, and for displaying a normalized representation. For hReview, since it expressely ignores HR-XML, only the second use case remains for "in-browser", which is still very valid. Aside from that, the "include pattern" is the key to represent more complex graphs of data in µformat.</p>

<blockquote>
  <blockquote>
    <p>My point is: so far, when there is scripting manipulation of the DOM, there are already problems for the existing in-browser microformat interpreters.
    If script manipulation is already a problem, does it make sense to make the problem worse?</p>
  </blockquote>
</blockquote>

<p>Worse compared to what? It sounds like XML namespaces is itself a fatality. I agree that the DOM Level 2 support in the current web browsers (and especially IE) is not up to the standard; but that does not explain why you dismiss the concept altogether. It's related to the next point.</p>

<blockquote>
  <p>Also, the people who implement the CSS cascade and the people who implement metadata scaping are not the same people.</p>
</blockquote>

<p>For "in-browser", we could expect that the people who implement the CSS cascade and those working on the DOM interfaces work at least as a team. For "standalone", I think there is no problem as of today finding an HTML normalizer + DOM Level 2 (if we want a brute force approach working on a non-standardized HTML 4 + RDFa).</p>

<blockquote>
  <p>That more code than no code. And what benefit do you get from the layer of indirection that Namespaces is at the end of the day?</p>
</blockquote>

<p>Last time I checked, you used Java Namespaces in your code, willingly, and you seem to be alive from that "more code". And you use "CSS Namespaces" as well in your pages (aka descendant selector applied to an ID selector). So, what are the benefits in qualifying a name? To me, it lies in the robustness aspect.</p>

<blockquote>
  <p>Furthermore, citing another case where values propagate in the tree (CSS, xml:lang, base URI, etc.) doesn't make QNames in content less brittle in the face of DOM manipulation.</p>
</blockquote>

<p>Once again, strictly speaking, I don't see anything brittle in Dom Level 3 Appendix B. But maybe I miss some piece of information. And, again, you have the same propagation mechanism in µformat as well (after all, they form a hierarchy).</p>

<p>To conclude, it seems that your position is that XML Namespace are not a robust mechanism in face of tree manipulations, and there I disagree.</p>

</div>
</div>


  <div class="comments-open" id="comments-open">
<h3 class="comments-open-header">Leave a comment</h3>

<div class="comments-open-moderated">
   <p>
   Note: this blog is intended to foster <strong>polite
   on-topic discussions</strong>. Comments failing these
   requirements and spam will not get published. Please,
   enter your real name and email address. Every
   individual comment is reviewed by the W3C staff.
   This may take some time, thank you for your patience.
   </p>
   <p>
   You can use the following HTML markup (a href, b, i,
   br/, p, strong, em, ul, ol, li, blockquote, pre)
   and/or <a href="http://daringfireball.net/projects/markdown/syntax">Markdown syntax</a>.</p>
</div>

<div id="comments-open-data">
<form method="post" action="http://www.w3.org/QA/sununga/beach.pl" id="comments-form">
<h4>Your comment</h4>
<div id="comments-open-text">
  <textarea id="comment-text" name="text" rows="20" cols="100"></textarea><br />
<label for="comment-text">Write your comment text here. Remember, keep the discussion on topic and courteous.</label>
</div>

<h4>About you</h4>
<div id="comment-form-name">
  <input type="hidden" name="static" value="1" />
<input type="hidden" name="entry_id" value="200" />
<input type="hidden" name="__lang" value="en" />
<label for="comment-author">Your Name</label>
<input id="comment-author" name="author" size="30" value="" />
</div>
<div id="comment-form-email">
<label for="comment-email">Your Email Address</label>
<input id="comment-email" name="email" size="30" value="" />
</div>

<div id="comments-open-footer">
<input type="submit" accesskey="s" name="post" id="comment-submit" value="Submit" />

</div>
</form>
</div>
</div>


<p id="gentime">This page was last generated on $Date: 2011/12/16 03:02:54 $</p>

      </div><!-- End of "main" DIV. -->

<address>

This blog is written by W3C staff and working group participants,<br />
&nbsp;and maintained by <a href="/People/CMercier/">Coralie Mercier</a>.<br />
Authorized parties may <a href="/QA/new">log in</a> to create a new entry.<br/>
<span id="poweredby">Powered by Movable Type, magpierss and a lot of Web Technology</span>
    </address>


    <p class="copyright">
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy; 1994-2011
      <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a>&reg;
      (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
      <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
      <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved.
      W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
      <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
      <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
      and <a rel="Copyright" href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a>
      rules apply. Your interactions with this site are in accordance
      with our <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Public">public</a> and
      <a href="http://www.w3.org/Consortium/Legal/privacy-statement#Members">Member</a> privacy
      statements.
    </p>

  </body>
</html>