orthogonal_specifications_is_good.html 16.1 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='ietf, quality, rdf, semantic web, sparql, w3c, web architecture' />
    <meta name="description" content="The HTML 4.01 specification has an IMG element, but there is no normative dependency on the PNG or GIF or JPEG specifications. &quot;What good is an HTML user agent that doesn't support GIFs?!?&quot; you might ask. And you wouldn't be..." />
    <meta name="revision" content="$Id: orthogonal_specifications_is_good.html,v 1.93 2011/12/16 02:58:22 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>When to standardize, especially an RDF API - W3C Blog</title>

   <link rel="start" href="http://www.w3.org/QA/" title="Home" />
   <link rel="prev" href="http://www.w3.org/QA/2007/03/w3c_is_hiring.html" title="W3C is hiring!" />
   <link rel="next" href="http://www.w3.org/QA/2007/03/new-html-working-wg.html" title="W3C Launches New HTML Working Group" />

   <!--
<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/03/orthogonal_specifications_is_good.html"
    trackback:ping="http://www.w3.org/QA/sununga/mt-tb.cgi/34"
    dc:title="When to standardize, especially an RDF API"
    dc:identifier="http://www.w3.org/QA/2007/03/orthogonal_specifications_is_good.html"
    dc:subject="Opinions &amp; Editorial"
    dc:description="The HTML 4.01 specification has an IMG element, but there is no normative dependency on the PNG or GIF or JPEG specifications. &quot;What good is an HTML user agent that doesn&apos;t support GIFs?!?&quot; you might ask. And you wouldn&apos;t be..."
    dc:creator="Dan Connolly"
    dc:date="2007-03-02T00:47:09+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/03/w3c_is_hiring.html">&laquo; W3C is hiring!</a> |
                        <a href="http://www.w3.org/QA/">Main</a>
                        | <a href="http://www.w3.org/QA/2007/03/new-html-working-wg.html">W3C Launches New HTML Working Group &raquo;</a>
                     </p>

                        <h2 class="entry-header">When to standardize, especially an RDF API</h2>
                           <div class="entry-body">
                              <p>The HTML 4.01 specification has an <a href="http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#edef-IMG">IMG element</a>, but there is no normative dependency on the PNG or GIF or JPEG specifications. "What good is an HTML user agent that doesn't support GIFs?!?" you might ask. And you wouldn't be alone. From the early days of W3C, there have been calls for a standard "web browser profile" component specification that listed which URI schemes (http, ftp, mailto, ...) and which formats (HTML 3.2, GIF, ...) and so on a standard web browser should support. It always seemed to me that the market would sort that out by itself and any standard, W3C could put in place, would be perennially out of date and irrelevant.
</p>

<p>According to the Web Architecture document, <a href="http://www.w3.org/TR/webarch/#orthogonal-specs">orthogonal specifications are a good thing</a>. In section <cite><a href="http://www.w3.org/TR/webarch/#orthogonal-specs">5.1. Orthogonal Specifications</a></cite>:</p>

<blockquote cite="http://www.w3.org/TR/webarch/#orthogonal-specs">
    <p>When two specifications are orthogonal, one may change one without requiring changes to the other, even if one has dependencies on the other. For example, although the <acronym title="HyperText Transfert Protocol">HTTP</acronym> specification depends on the URI specification, the two may evolve independently. This orthogonality increases the flexibility and robustness of the Web.</p>
</blockquote>

<p>W3C inherited from the <acronym title="Internet Engineering Task Force">IETF</acronym> a bias for specifying interfaces rather than components; i.e. data formats and protocols rather than software modules. I gather that in TV/consumer electronics, there are useful component standards for Web User Agents. But note that an in-car voice browser or a screen reader or good old lynx doesn't support PNG nor GIF, and while their marketplaces are perhaps smaller than desktop or mobile screen-oriented browsers, they're pretty much first-class citizens as far as W3C specifications, especially Web Architecture, are concerned.</p>

<p><acronym title="Application Programming Interface">API</acronym>s are more like interfaces than components, but they tend to be tied to platforms. The IETF has a cultural bias for on-the-wire formats over APIs, and for good reasons, I think. With OMG specs, at least the early CORBA specs, lots of products conformed to the spec (or at least claimed to) without actually interoperating with each other. It wasn't until the arrival of IIOP, <a href="http://acmqueue.com/modules.php?name=Content&amp;pa=showpage&amp;pid=396">an on-the-wire CORBA format</a>, that the rubber hit the road and the interoperability issues got addressed.</p>

<p>Meanwhile, the IETF's aversion to APIs is not without exception: witness <a href="http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface">GSSAPI</a>. And the W3C has been doing Javascript APIs in the form of the DOM since the early days of XML. Some argue that the DOM specs are ugly, and I tend to agree. SAX and JDOM and the libxml2 pull API have a more elegant feel. But with DHTML and AJAX, one has to wonder: did the W3C DOM Recommendations do more harm or good? Sometimes a mediocre standard is better than no standard. It's clear to me that HTML standardization does more good than harm, but I don't pretend that the HTML design is a thing of beauty.</p>

<p>W3C also started out with a bias against standardizing programming languages. The principle of least power is a part of the lore that the TAG has recently adopted in a <a href="http://www.w3.org/2001/tag/doc/leastPower">finding</a>. For those reasons, when the Javascript designers were looking for a standardization forum in 1996 or so, I let it go to ECMA rather than arguing that it should be done at W3C. The fact that XSLT is turing-complete went under the radar a little bit at first; the WG was able to negotiate requirements by noting that its intended scope was formatting XML documents, not transformations in general. And I heard many times that people who don't see themselves writing Java programs are happy to develop XSLT transformations. But I had very strong misgivings about crossing that line. By the time I was reviewing XQuery/XPath 2.0 functions and operators, I disregarded any claims about narrow scope and looked at it as the standard library for the new computing platform that it is.</p>


<p>And now with the Rich Client Activity and the <a href="http://www.w3.org/2006/webapi/">Web API WG</a>, we're fully engaged in standardization of Javascript APIs with no pretense about language independence. It remains to be seen whether we're actually going to tackle enough of the security policy issues to standardize a real platform or whether we need to just leave that to the market for a while. But enough of the right people seem to be involved in the work on XMLHTTPRequest to make me think we're doing more good than harm there. I haven't seen enough test cases for my tastes yet, but I gather they're on the way.</p>

<p>I don't do much of Javascript hacking myself, but I gather it's an unholy mess of incompatibilities. "Where was W3C when XMLHTTPRequest was being designed in the first place?" you might ask. Maybe we were asleep at the wheel and we could and should have prevented the mess. But maybe we were in "mostly harmless" or "first do no harm" mode, letting the market establish what's really needed. I was dead set on tackling multi-namespace integration in the first version of XML Schema, but in hindsight it's pretty clear to me that we should have gone a little slower, i.e. started with a smaller scope.</p>

<p>The question of when and whether to <a href="http://esw.w3.org/topic/WebDataInterfaceDesign">standardize an RDF API</a> has been hanging in the air for a decade or so. My personal experience with python APIs for RDF suggests that, for example, there's a core of cwm and rdflib and redland that is the same except for a few coin-toss issues. And there are several mature Java APIs and the tabulator has an RDF store in Javascript. Meanwhile, SPARQL is maturing; maybe, like SQL, the string format of queries (and other operations) is the main thing we need to standardize. A survey
on <cite><a href="http://www.w3.org/2002/09/wbs/1/semweb-js-api/">Standardizing a Semantic Web API for Javascript</a> is open. Please let us know what you think.</p>


<p>There are precious few "W3C should never do XYZ" rules that I think are worth setting in stone. While we will naturally attract work that is like what we have done before, any place we can get a critical mass of the marketplace to get together and do the hard work of testing, internationalization, accessibility in a reasonably timely, fair and accountable way is a place where W3C should be able to do more good than harm.</p>
                           </div>
                           <div id="more" class="entry-more">

                           </div>
                       <p class="postinfo">Filed by <a href="http://www.w3.org/People/Connolly/">Dan Connolly</a> on March  2, 2007 12:47 AM in <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/web_architecture/">Web Architecture</a><br />
<span class="separator">|</span> <a class="permalink" href="http://www.w3.org/QA/2007/03/orthogonal_specifications_is_good.html">Permalink</a>
                                 | <a href="http://www.w3.org/QA/2007/03/orthogonal_specifications_is_good.html#comments">Comments (1)</a>
                                 | <a href="http://www.w3.org/QA/2007/03/orthogonal_specifications_is_good.html#trackback">TrackBacks (0)</a>
</p>


<h3 class="comments-header" id="comments">Comments</h3>
<div class="comment" id="comment-24641">
<p class="comment-meta" id="c024641">
<span class="comment-meta-author"><strong>Chimezie Ogbuji </strong></span>
<span class="comment-meta-date"><a href="#c024641">#</a> 2007-03-09</span>
</p>
<div class="comment-bulk">
<p>For me the question of RDF APIs will not be addressed by SPARQL and what is needed is essentially DOM for RDF.  It would be nice for instance if RDF python code can be written once for <em>either</em> of redland/rdflib/cwm and same for any other Java solution...  That should be the goal </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="34" />
<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:22 $</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>