version_identifiers_reconsider.html 25.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='' />
    <meta name="description" content="The Architecture of the World Wide Web includes a section on extensibility and versioning of languages and data formats.  The TAG is having second thoughts about the suggestion that all data formats SHOULD provide for version identification.  Sometimes it is a good thing to do, but sometimes not. " />
    <meta name="revision" content="$Id: version_identifiers_reconsider.html,v 1.71 2011/12/16 02:58:42 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>Version Identifiers Reconsidered - W3C Blog</title>

   <link rel="start" href="http://www.w3.org/QA/" title="Home" />
   <link rel="prev" href="http://www.w3.org/QA/2007/12/when_will_html_5_support_soone.html" title="When will HTML 5 support &amp;amp;lt;video&amp;gt;? Sooner if you help" />
   <link rel="next" href="http://www.w3.org/QA/2007/12/when_widgets_go_wrong.html" title="When Widgets Go Wrong" />

   <!--
<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/2007/12/version_identifiers_reconsider.html"
    trackback:ping="http://www.w3.org/QA/sununga/mt-tb.cgi/117"
    dc:title="Version Identifiers Reconsidered"
    dc:identifier="http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html"
    dc:subject="Web Architecture"
    dc:description="The &lt;a href=&quot;http://www.w3.org/TR/webarch/&quot;&gt;Architecture of the World Wide Web&lt;/a&gt; includes a &lt;a href=&quot;http://www.w3.org/TR/webarch/#ext-version&quot;&gt;section&lt;/a&gt; on extensibility and versioning of languages and data formats.  The TAG is having second thoughts about the suggestion that all data formats SHOULD provide for version identification.  Sometimes it is a good thing to do, but sometimes not. "
    dc:creator="Noah Mendelsohn"
    dc:date="2007-12-18T18:10:15+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/2007/12/when_will_html_5_support_soone.html">&laquo; When will HTML 5 support &lt;video>? Sooner if you help</a> |
                        <a href="http://www.w3.org/QA/">Main</a>
                        | <a href="http://www.w3.org/QA/2007/12/when_widgets_go_wrong.html">When Widgets Go Wrong &raquo;</a>
                     </p>

                        <h2 class="entry-header">Version Identifiers Reconsidered</h2>
                           <div class="entry-body">
                              <p>
The <a href="http://www.w3.org/TR/webarch/">Architecture of the World Wide Web</a> includes a <a href="http://www.w3.org/TR/webarch/#ext-version">section</a> on extensibility and versioning of languages and data formats.  Quoting from the architecture document:</p>
<div style="border: solid #bebebe 1px; margin: 2em 1em 1em 2em;">
<p><a name="quotedPractice" id="quotedPractice"></a> <span style="margin: 1.5em 0.5em 1em 1em; font-weight: bold; font-style: italic; background: #dfffff; position: relative; padding: 0 0.5em;  top: -1.5em;" >Good practice: <a name="pr-version-info" id="pr-version-info" shape="rect">Version information</a></span></p>
<p style=" margin: 1.5em 0.5em 1em 1em; position: relative; top: -2em;
   padding: 0; margin: 1.5em 0.5em -1em 1em;"><a name="p220" id="p220"></a> A data format specification SHOULD provide for version information.
</p>
</div>
<p>
So, it's always a good idea when you design a language or data format to provide a way for instance documents to include something like a version attribute, probably near the beginning of the document, to indicate what version of the language is being used.  </p>
<p>
Or is it always a good idea?</p>
<p><strong>What does a version identifier convey?</strong></p>
<p>
In fact, do we even agree on what it means to put something like a language version marker on a document?   Let's imagine a simple XML language designed for setting down recipes.  In the first version of the language, the markup looks like this:</p>
<pre><code>
&lt;recipe name="Tuna Salad" <strong>recipeLanguageVersion="1.0"></strong>
  &lt;ingredients>
    &lt;ingredient name="Tuna Fish"  amount="1 can"/>
    &lt;ingredient name="Mayonnaise" amount="3 tablespoons"/>
    &lt;ingredient name="Capers" amount="a few"/>
  &lt;/ingredients>
  &lt;steps>
    &lt;step>Open can&lt;/step>
    &lt;step>Drain liquid from can.  Put fish in bowl.&lt;/step>
    &lt;step>Add mayonnaise.  Stir well.&lt;/step>
    &lt;step>Add capers.  Stir gently.&lt;/step>
  &lt;/steps>
&lt;/recipe>
</code></pre>
<p>
The allowed markup in version 1.0 of the recipe is just what's shown above: an outer &lt;recipe> containing &lt;ingredients> and &lt;steps>, etc.
Eventually it's decided that it would be useful to provide optional pictures for ingredients or steps.  So in version 2 of the language we can do things like:</p>
<pre><code>
&lt;recipe name="Tuna Salad" <strong>recipeLanguageVersion="2.0"</strong>>
  &lt;ingredients>
    &lt;ingredient name="Tuna Fish"  amount="1 can"
                <strong>picture="./CanPicture.jpg"</strong>/>
    &lt;ingredient name="Mayonnaise" amount="3 tablespoons"/>
    &lt;ingredient name="Capers" amount="a few"/>
  &lt;/ingredients>
  &lt;steps>
    &lt;step>Open can&lt;/step>
    &lt;step <strong>picture="./DrainCanPicture.jpg"</strong>>
           Drain liquid from can.  Put fish in bowl.&lt;/step>
    &lt;step>Add mayonnaise.  Stir well.&lt;/step>
    &lt;step>Add capers.  Stir gently.&lt;/step>
  &lt;/steps>
&lt;/recipe>
</code></pre>
<p>
Question: let's imagine that version 2 of the language, the one that supports the optional pictures, has been out for awhile, but I still want to write a simple recipe with no pictures:</p>
<pre><code>
&lt;recipe name="ice cubes" <strong>recipeLanguageVersion="??"</strong>>
  &lt;ingredients>
    &lt;ingredient name="water"  amount="1.5 cups"
  &lt;/ingredients>
  &lt;steps>
    &lt;step>Put water into ice cube tray.&lt;/step>
    &lt;step>Freeze.&lt;/step>
  &lt;/steps>
&lt;/recipe>
</code></pre>
<p>
What's the best value to put in the version attribute?  I know that version 2.0 is the latest version of the recipe language.  In fact, that's the only version of the specification I have next to me, so maybe I should use that?
There's a problem, though.  That <code>version="2.0"</code> marker might not work with software that's written to version 1.0, and in fact, my document would otherwise be a fine 1.0 recipe document.</p>
<p>
So, maybe I should label it 1.0?  Unfortunately, that's a bit hard for me.  I don't want to have to go through the specifications for every version of the recipe language that's ever existed just to find the oldest that works. I really don't want to do that if the language has been revised a lot!  Also, these sample recipes are small, but if I were using software to write very long documents, then that software would either have to keep track of the latest features used, or else search the entire document before writing it to a file, in order to get that version identifier at the front.
</p>
<p>Indeed, just these complexities have proven troublesome for the deployment of
languages like XML 1.1.  XML 1.1 is similar to XML 1.0, but it enables the use of some new Unicode characters (just as recipe language V2 allows for use of new image tags.)
The <a href="http://www.w3.org/TR/xml11/">XML 1.1</a> Recommendation suggests that:</p>
<blockquote>
<p>
XML Programs which generate XML SHOULD generate XML 1.0, unless one of the specific features of XML 1.1 is required.</p>
</blockquote>
<p>
In fact, it has often proven difficult to write software that generates documents labeled as XML 1.1 only when necessary:  it's much easier for XML 1.1-compatible software to label all output as <code>&lt;xml version="1.1"></code>, resulting in documents that are unusable with widely deployed XML 1.0 software.
Perhaps for reasons like this, adoption of XML 1.1 has been slow.</p>
<p>
Returning to the recipe example, maybe the version attribute should take a list of versions, and I should put in both 1.0 and 2.0?  That could be helpful to consuming software, but it still means that I (or my software) must be familiar with all the previous versions of the specification.</p>
<p>
So, we need to ask, is the version identifier used to convey:</p>
<ul>
<li>The earliest version of the language with which the document is compatible (1.0 in the recipe example)?</li>
<li>The version of the specification I used as a guide when writing the document (2.0)?</li>
<li>A list of versions with which the document is compatible?</li>
<li>Something else?</li>
</ul>
<p>
The best answer is probably different depending on the language, how often it's revised, whether revisions tend to maintain backwards compatibility, etc.</p>
<p><strong>Is having some sort of version identifier always a good idea?</strong></p>
<p>
That Good Practice Note quoted above says "provide a version indicator", but we've just shown that we're not always quite clear on what that would do anyway.  Is it still good advice to suggest that surely each language should provide for  <i>something</i> in the instance?  If so, should its use be required or optional?</p>
<p>
As shown above, it's common for the same instance document to be legal in many versions of a language.
As long as such documents are likely to have the same or sufficiently compatible meanings per the different versions, then it may be better to omit any indication of version in the instance, and leave it to the receiving software to decide whether the document can be processed.  After all, with the second recipe above, the receiver will soon enough discover that it can or can't process picture attributes, and if not, it either will or won't know that they can be safely ignored.  Version attributes can be helpful in giving early warning of incompatibilities, or as a crosscheck for catching errors, but they're usually not essential to correct operation.</p>
<p>
One important exception is in the case where the language is likely to change in incompatible ways.  If the same document means different things in different versions of a language, then it's very important to indicate which version the author had in mind when creating the document.  Putting that version indicator into the document itself is one good way to do it.  So maybe the right advice is:</p>
<div style="border: solid #bebebe 1px; margin: 2em 1em 1em 2em;">
<p><a name="quotedPractice" id="quotedPractice"></a> <span style="margin: 1.5em 0.5em 1em 1em; font-weight: bold; font-style: italic; background: yellow; position: relative; padding: 0 0.5em;  top: -1.5em;" >Proposal for Future Architecture Document: <a name="pr-incompatversion" id="pr-incompatversion" shape="rect">Version information</a></span></p>
<p style=" margin: 1.5em 0.5em 1em 1em; position: relative; top: -2em;
   padding: 0; margin: 1.5em 0.5em -1em 1em;"><a name="p220" id="p220"></a>
If a language or data format will change in incompatible ways, then indicate the language version used for each instance.</p>
</div>


<p><strong>
Are namespaces a good way to identify language versions?</strong></p>
<p>
If version identifiers aren't always a good bet, what about namespaces?  Many modern languages allow the creation of globally unique names, identifiers, tags, etc.  In XML this is done through use of <a href="http://www.w3.org/TR/xml-names11/">Namespaces</a>.   In RDF, it's done by using URIs as identifiers, etc.. </p>
<p>
Sometimes it's appropriate to use new identifiers for each version of a language, and mechanisms like namespaces can make that easier:</p>
<pre><code>
	&lt;r:step xmlns:r="http://example.org/<strong>recipeLanguage1</strong>">
</code></pre>
<p>
vs.</p>
<pre><code>
	&lt;r2:step <strong>picture="./food.jpg"</strong>
                 xmlns:r2="http://example.org/<strong>recipeLanguage2</strong>">
</code></pre>
<p>
In this example, the element with expanded name <code>{http://example.org/recipeLanguage2, step}</code> allows a picture attribute, but <code>{http://example.org/recipeLanguage1, step}</code> does not.</p>
<p>
A full discussions of the pros and cons of using namespaces this way is beyond the scope of this note.  One important advantage of using namespaces is that they can be easily applied not just to the root element for the language as a whole, but to mixtures of compound document markup, in which each sublanguage evolves with its own namespaces.  Also, because namespace names are URIs, you can use the Web itself to get information about them.  </p>
<p>
Namespaces do have drawbacks.  Imagine if there were 50 different namespaces for a language just because 50 separate bugs had been fixed in different errata.  Would you republish all the markup in 50 namespaces?  Would each document have lots of namespaces, with each element named with the last namespace in which it had been revised?  Namespaces can be very useful for designating language versions, but there's no one idiom that's right for all languages.  We note that most widely deployed tag-based languages for the Web (HTML, XML Schema, XSLT) have chosen either to use the same namespace(s) across multiple versions, or in the case of some flavors of HTML, not to use namespaces at all.</p>
<p><strong>Conclusions</strong></p>
<p>
So, the TAG is having second thoughts about the suggestion that all data formats SHOULD provide for version identification.  Sometimes it's a good thing to do, but sometimes not.
Perhaps the right advice will be what's proposed in the revised Good Practice Note above.
In any case, the TAG has been working for several years on a finding that will explore in detail many issues relating to versioning, and version attributes are likely to be among the topics covered.  In the meantime, we thought we'd take the opportunity to signal that we're not so sure that the advice in the Architecture Document is as good as we thought.  </p>
<p>
By the way, TAG member David Orchard has covered some of the same topics as well as many others relating to versioning in his personal blog.  Links to a few of his postings follow my signature below.  Dave is also the principle author of the TAG's draft finding on versioning.  Working drafts covering <a href="http://www.w3.org/2001/tag/doc/versioning">Terminology</a>, <a href="http://www.w3.org/2001/tag/doc/versioning-strategies">Strategies</a>, and <a href="http://www.w3.org/2001/tag/doc/versioning-xml">Versioning of XML Languages</a> are available for review.  New drafts come out every few months, and we're hoping to have something more or less complete, well, real soon now.</p>
<p>
Noah Mendelsohn
</p>
<p class="smallnote">
Note: unless otherwise indicated, opinions expressed in the TAG's blog are those of the individual authors, and do not necessarily represent consensus of the TAG as a whole.</p>

<p><strong>Links to Dave Orchard's Blog Postings on Versioning</strong></p>
<ul>
<li><a href="http://www.pacificspirit.com/blog/2007/04/19/what_do_version_identifiers_identify">http://www.pacificspirit.com/blog/2007/04/19/what_do_version_identifiers_identify</a></li>
<li><a href="http://www.pacificspirit.com/blog/2007/04/19/forwards_compatibility_with_version_s_requires_version_mapping">http://www.pacificspirit.com/blog/2007/04/19/forwards_compatibility_with_version_s_requires_version_mapping</a></li>
<li><a href="http://www.pacificspirit.com/blog/2007/04/20/how_to_have_multiple_namespaces_per_name">http://www.pacificspirit.com/blog/2007/04/20/how_to_have_multiple_namespaces_per_name</a></li>
<li><a href="http://www.pacificspirit.com/blog/2007/08/09/guide_to_versioning_xml_languages_using_new_xml_schema_11_features_published">http://www.pacificspirit.com/blog/2007/08/09/guide_to_versioning_xml_languages_using_new_xml_schema_11_features_published</a></li>
<li><a href="http://www.pacificspirit.com/blog/2007/09/13/when_can_language_components_be_removed_and_maintain_backwards_or_forwards_compatibility">http://www.pacificspirit.com/blog/2007/09/13/when_can_language_components_be_removed_and_maintain_backwards_or_forwards_compatibility</a></li>
<li><a href="http://www.pacificspirit.com/blog/2007/12/12/validation_by_projection_introduction">http://www.pacificspirit.com/blog/2007/12/12/validation_by_projection_introduction</a></li>
</ul>


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

                           </div>
                       <p class="postinfo">Filed by <a href="">Noah Mendelsohn</a> on December 18, 2007  6:10 PM in <a href="http://www.w3.org/QA/archive/web_architecture/">Web Architecture</a><br />
<span class="separator">|</span> <a class="permalink" href="http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html">Permalink</a>
                                 | <a href="http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html#comments">Comments (4)</a>
                                 | <a href="http://www.w3.org/QA/2007/12/version_identifiers_reconsider.html#trackback">TrackBacks (0)</a>
</p>


<h3 class="comments-header" id="comments">Comments</h3>
<div class="comment" id="comment-96931">
<p class="comment-meta" id="c096931">
<span class="comment-meta-author"><strong>John Cowan </strong></span>
<span class="comment-meta-date"><a href="#c096931">#</a> 2008-01-01</span>
</p>
<div class="comment-bulk">
<p>I think you are right: version numbers should be bumped only in the case of incompatible changes -- but then, of course, you bump up against the notion of "incompatible change."  Since the semantics of most formats are defined basically by the programs that use them (with a few honorable exceptions like regular expressions), is a change to such a program an incompatible change?</p>

<p>As for XML 1.1, my motive in pushing it through the W3C was justice.  Since I failed in doing it the right way, I'm now engaged in doing it the wrong way.  Google for "XML 1.0 Fifth Edition".</p>

</div>
</div>


<div class="comment" id="comment-100965">
<p class="comment-meta" id="c100965">
<span class="comment-meta-author"><strong>Paul Walsh </strong></span>
<span class="comment-meta-date"><a href="#c100965">#</a> 2008-01-13</span>
</p>
<div class="comment-bulk">
<p>Would it not be possible to recompile the incompatible software that doesn't understand "version 2" ?</p>

</div>
</div>


<div class="comment" id="comment-116175">
<p class="comment-meta" id="c116175">
<span class="comment-meta-author"><strong>Noah Mendelsohn </strong></span>
<span class="comment-meta-date"><a href="#c116175">#</a> 2008-02-19</span>
</p>
<div class="comment-bulk">
<p>Paul Walsh asks:</p>

<blockquote>
  <p>"Would it not be possible to
  recompile the incompatible
  software that doesn't understand
  "version 2"?"</p>
</blockquote>

<p>I think the answer depends on the circumstance.  Many of the languages used on the Web are consumed by programs that have been deployed by many millions of users.  Even in situations where recompiling or even rewriting the application is easy, it often takes years before even a majority of users upgrade their individual copies.  For example, from the time a new browser release is made available by its authors, how long does it typically take until the majority of users of the earlier versions have upgraded?  Usually, on the Web, we have to anticipate that mismatches between deployed versions of software will be common, and will persist for long periods of time.  That's one of the reasons that versioning issues are particularly important in the context of the Web.</p>

<p>Noah Mendelsohn </p>

</div>
</div>


<div class="comment" id="comment-198088">
<p class="comment-meta" id="c198088">
<span class="comment-meta-author"><strong>Patrice Scribe </strong></span>
<span class="comment-meta-date"><a href="#c198088">#</a> 2010-08-06</span>
</p>
<div class="comment-bulk">
<p>Hi,</p>

<p>I wonder if we shouldn't have actually two mechanisms. A version number whose sole purpose would be to process a particular tag according to an old standard (for example when reusing in a new spec something what was previously deprecated).</p>

<p>Perhaps HTML could also include a mechanism to allow to be more explicit about what to do if a particular tag is not supported by the user agent. Something like allowing the user agent to use a replacement (perhaps based on a transform for maximum flexibility). It would allow to explicitely define a markup fallback when a particular tag is not provided by a user agent. The replacement won't be used any more as soon as the user agent starts supporting the feature...</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="127" />
<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 02:58:42 $</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>