31-tagmem-minutes 46.1 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta name="generator" content=
  "HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org" />

  <title>TAG in Mountain View -- 31 May 2007</title>
  <link type="text/css" rel="STYLESHEET" href=
  "http://www.w3.org/StyleSheets/base.css" />
  <link type="text/css" rel="STYLESHEET" href=
  "http://www.w3.org/StyleSheets/public.css" />
  <link type="text/css" rel="STYLESHEET" href=
  "http://www.w3.org/2004/02/minutes-style.css" />
  <meta content="TAG in Mountain View" name="Title" />
  <meta content="text/html; charset=us-ascii" http-equiv=
  "Content-Type" />
</head>

<body>
  <p><a href="http://www.w3.org/"><img src=
  "http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
  "48" width="72" /></a></p>

  <h1>- DRAFT -</h1>

  <h1>TAG in Mountain View</h1>

  <h2>31 May 2007</h2>

  <p>See also: <a href="29-agenda">agenda</a>, <a href=
  "http://www.w3.org/2007/05/31-tagmem-irc">IRC log</a></p>

  <h2><a name="attendees" id="attendees">Attendees</a></h2>

  <div class="intro">
    <dl>
      <dt>Present</dt>

      <dd>SW, RL, NDW, DC, TBL, HT, TVR, NM, DO, Ian_Hickson</dd>

      <dt>Regrets</dt>

      <dt>Chair</dt>

      <dd>SW</dd>

      <dt>Scribe</dt>

      <dd>Henry S. Thompson, Dan Connolly</dd>
    </dl>
  </div>

  <h2>Contents</h2>

  <ul>
    <li>
      <a href="#agenda">Topics</a>

      <ol>
        <li><a href="#item01">Directions and Priorities</a></li>

        <li><a href="#item02">TAG Web presence</a></li>

        <li><a href="#item03">Dereferencing HTTP URIs,
        resumed</a></li>

        <li><a href="#item04">Version Identification</a></li>

        <li><a href="#item05">Henry's work on tag soup</a></li>
      </ol>
    </li>

    <li><a href="#ActionSummary">Summary of Action Items</a></li>
  </ul>
  <hr />

  <div class="meeting">
    <p class='phone'></p>

    <p class='phone'></p>

    <h3 id="item01">Directions and Priorities</h3>

    <p class='irc'>&lt;<cite>ht_google</cite>&gt; Scribe: Henry S.
    Thompson</p>

    <p class='irc'>&lt;<cite>ht_google</cite>&gt; ScribeNick:
    ht_google</p>

    <p class='phone'>some breakfast noodling on upcoming TAG
    priorities...</p>

    <p class='phone'>1) Semantic Web Arch</p>

    <p class='phone'>2) Web 2.0</p>

    <p class='phone'>State; programs; what should have URIs, and
    how</p>

    <p class='phone'>3) Where can we have an impact</p>

    <p class='phone'>4) Injecting more sense of urgency</p>

    <p class='phone'><strong class='resolution'>RESOLUTION: Revisit
    Monday 1700GMT meeting time after the summer</strong></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; Stuart asked us at
    breakfast to noodle on upcoming TAG priorities. I heard two big
    themes:</p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; From Tim and later
    endorsed by Noah: Semantic Web</p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; From Henry, Dave and
    others: Web 2.0</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; In think our
    priorities should be guided by how much effect we can have.</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; That's why we have
    de-emphasized Web Services</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; I also think that
    Stateful clients are becoming much more prevalent as Rich
    Client Apps become more larger and more stateful</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; This has effects
    on REST, use of URIs, and stateful vs stateless apps</p>

    <p class='irc'>&lt;<cite>raman</cite>&gt; Web Arch is complete
    with respect to what was well understood in 2000. Things that
    were left unsaid in Web Arch 1.0 have provided room for
    innovation --- leading to dynamic Web applications on the data
    driven Web. Now that we have seen how the Web has evolved, what
    are the next set of architectural principles we can add to Web
    Arch to make it more complete with respect to how the Web looks
    today? This might be an essential step to</p>

    <p class='irc'>&lt;<cite>raman</cite>&gt; ensure that the next
    phase of evolution progresses from a well-understood,
    well-documented base.</p>

    <p class='phone'><cite>NW:</cite> Post-WebArch1.0, will the
    outline of WebArch2.0 emerge?</p>

    <p class='phone'><cite>SW:</cite> Updating WebArch1.0 is a
    possible work item<br />
    ... Version identification and Mime Type respect are possible
    areas for revision</p>

    <p class='phone'><cite>DC:</cite> Working with our customers
    would be good, it would identify more possible gaps<br />
    ... HTML WG, CDF WG</p>

    <p class='phone'><cite>TBL:</cite> SWD/SWEO, ATOM</p>

    <p class='irc'>&lt;<cite>raman</cite>&gt; backplane work</p>

    <p class='phone'><cite>RL:</cite> UWA</p>

    <p class='phone'><cite>DC:</cite> More approachable W3C specs.
    . .</p>

    <p class='phone'><cite>TVR:</cite> Is that our job?</p>

    <p class='phone'><cite>RL:</cite> I don't see the Web2.0/SemWeb
    divide as very large, there's more in common than there are
    differences</p>

    <p class='phone'><cite>NM:</cite> Both of these are really just
    reality checks on what we do, which is independent/foundational
    wrt both of them</p>

    <p class='phone'><cite>TVR:</cite> Both W2.0 and SW are natural
    evolutions of the original Web, and WebArch should grow to
    manifest this</p>

    <p class='phone'><cite>SW:</cite> WebArch1.0 tried to focus on
    Identification, Representation and Interaction -- do we need a
    new one?</p>

    <p class='phone'>HST, TVR: No, but much more on Interaction,
    which isn't well represented in WebArch1.0</p>

    <p class='phone'><cite>NM:</cite> Bill Gates said "The
    important standards are the ones on the wire" -- I tend to feel
    parallel to that to the effect that the stuff going on between
    the user and the browser don't matter very much<br />
    ... That's wrong, they're important, just perhaps a bit less
    than what comes over the wire</p>

    <p class='phone'><cite>TBL:</cite> Javascript doesn't change
    things, it's components are the functions you can call, so its
    an on-the-wire standard just as well</p>

    <p class='phone'><cite>NM:</cite> Yes, but when you start
    looking at e.g. event percolation up the window hierarchy, I
    don't see how that was on the wire</p>

    <p class='phone'><cite>SW:</cite> I'm with TBL on this</p>

    <p class='phone'><cite>TVR:</cite> It's state that makes things
    different<br />
    ... Repeatability of actions, whether its on-screen, by user,
    or not, is what matters</p>

    <p class='phone'><cite>NM:</cite> Yes, we need to be careful
    about our definition of Interaction -- it's not just
    user-&gt;machine</p>

    <p class='phone'><cite>SW:</cite> What should we focus on at
    our next f2f?</p>

    <p class='phone'><cite>DO:</cite> Versioning and Web2.0</p>

    <p class='phone'><cite>SW:</cite> If we did WebArch 2.0, what
    would be in it</p>

    <p class='phone'><cite>TBL:</cite> Norm&amp;I should finish our
    doc, that would be a start</p>

    <p class='phone'><cite>HST:</cite> Add self-describing web and
    xml functions</p>

    <p class='phone'><cite>SW:</cite> What about our public
    face?</p>

    <p class='phone'><cite>HST:</cite> I'd like to carry the
    summary I did forward, but I don't have the time to commit</p>

    <p class='phone'>TBL does whiteboard and DanC projected editing
    of possible ToC for WebArch Vol II</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/webarch2-outline">possible
    ToC for WebArch Vol II</a></p>

    <p class='phone'><cite>HST:</cite> The Interaction topic
    reminds me -- another way in which WebArch is not complete is
    that we can no longer treat "User Agent" as a simple cover term
    -- the more interaction there is from a page, the less what a
    browser presents is available to crawlers, indexes, etc.</p>

    <p class='phone'><cite>NM:</cite> That's close to something we
    did cover in the Least Power finding</p>

    <p class='phone'><cite>TVR:</cite> Not much thought is going
    into what is visible and what isn't</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted
    to note "unobtrusive javascript" good stuff from WAI/weblog
    world and to note that some crawler vendors are looking at
    javascript runtimes to combat fraud/spam</p>

    <p class='phone'><cite>DC:</cite> The basic principle of
    "unobtrusive javascript" (?) is that things should still work
    if script is turned off<br />
    ... Sometimes you're just dead in the water</p>

    <p class='irc'>&lt;<cite>raman</cite>&gt; <a href=
    "http://onlinetools.org/articles/unobtrusivejavascript/">http://onlinetools.org/articles/unobtrusivejavascript/</a></p>

    <p class='irc'>&lt;<cite>raman</cite>&gt; <a href=
    "http://www.google.com/search?e=StructuredResults&amp;q=%22loading+%2E%2E%2E%22&amp;num=25">
    http://www.google.com/search?e=StructuredResults&amp;q=%22loading+%2E%2E%2E%22&amp;num=25</a>
    says Web Results 1 - 25 of about 336,000,000 for "loading ...".
    (0.11 seconds)</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted
    to note that some crawler vendors are looking at javascript
    runtimes to combat fraud/spam</p>

    <p class='phone'><cite>DC:</cite> Crawler adding javascript
    engine, to get past innocuous static HTML to the
    script-generated e.g. porn spam</p>

    <p class='phone'><cite>TVR:</cite> Indexers can't afford to run
    huge amounts of script to get at the material to index</p>

    <p class='phone'>HT, DO: Encouraged by DC's draft ToC</p>

    <p class='phone'><cite>DO:</cite> It won't last, but it's a
    good start</p>

    <p class='phone'><cite>NM:</cite> Really mean package this in a
    separate volume<br />
    ... goal is to serve the customer, not to recapitulate our
    history<br />
    ... One volume or two is a decision for later</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; <a href=
    "http://en.wikipedia.org/wiki/Unobtrusive_JavaScript">Unobtrusive
    JavaScript</a></p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted
    to think out loud about tactics</p>

    <p class='phone'><cite>HST:</cite> Similarly, as in WA1, we
    don't just dump findings in to a document, we summarise and hit
    highlights of findings which are still published elsewhere</p>

    <p class='phone'><cite>TBL:</cite> Dependency diagram is a very
    useful tool</p>

    <p class='phone'><cite>SW:</cite> DC called it a "How-Why"
    document?</p>

    <p class='phone'><cite>DC:</cite> Each arrow is Why in one
    direction and How in the other</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; timbl drew a
    how/why diagram on the board. noah takes a photo.</p>

    <p class='phone'><cite>DC:</cite> It would be good to have an
    editor for this document, so it took on some reality<br />
    ... E.g. NDW</p>

    <p class='phone'>[General approbation]</p>

    <p class='phone'><cite>NW:</cite> I'll give it a try</p>

    <h3 id="item02">TAG Web presence</h3>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; [oops; growing
    list of things to say]: * group home page (move history) * link
    to ht's summaries * issue tracking garbage collect, tools *
    education business model * community/trust experiment *
    semantic mediawiki</p>

    <p class='phone'><cite>HST:</cite> I produced a one para
    summary of all the areas of current TAG activity for an online
    mag. -- it would be a good thing if that were prominently
    linked from the home page and kept up to date</p>

    <p class='phone'><cite>DC:</cite> I might try to take that
    forward a bit</p>

    <p class='phone'><a href=
    "http://www.ariadne.ac.uk/issue51/thompson/">http://www.ariadne.ac.uk/issue51/thompson/</a></p>

    <p class='irc'>&lt;<cite>Norm</cite>&gt; I observe that several
    of us have blogs; if we agreed to use a particular tag (no pun
    intended), we could aggregate one automatically</p>

    <p class='phone'><cite>SW:</cite> I'm very unsatisfied with the
    way I have to work to maintain the issues list, editing raw XML
    -- I'd like a forms-based interface</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; yes, aggregation
    looks cost-effective</p>

    <p class='phone'><cite>SW:</cite> There is new support for home
    page + issues list maintainance from W3C, maybe we should move
    to that</p>

    <p class='phone'><cite>TVR:</cite> We should have a blog, to
    allow TAG members to write down useful small conclusions</p>

    <p class='phone'><cite>DC:</cite> I should take the current
    page and reduce its weight, to make it more useful for the TAG
    as it tries to do its work<br />
    ... I'm certainly prepared to look at GCing the issues list and
    porting it to Tracker<br />
    ... Education materials -- W3C is looking at this as a service
    which would generate revenue, might look at this<br />
    ... Would like to try semantic mediawiki some time. . .</p>

    <p class='phone'><cite>RL:</cite> +1 to mediawiki</p>

    <p class='phone'><cite>DC:</cite> Should we use Technorati tags
    for the TAG and aggregate from e.g. NW and DO's blogs?</p>

    <p class='phone'>NW, DO: Yes</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; (I don't mean
    technorati per say; I mean rel="tag")</p>

    <p class='phone'><cite>DO:</cite> Blogging is a real
    opportunity, we should be doing our business in a more Web2.0
    fashion<br />
    ... recapture the community's interest in what we're doing</p>

    <p class='phone'><cite>RL:</cite> Agree we should upgrade our
    tools/web resources -- very hard to find things. I've used and
    like Tracker<br />
    ... Prepared to contribute some time</p>

    <p class='phone'><cite>NM:</cite> If we do a blog, we need to
    look very carefully at what it's for and how we use it -- is it
    for carefully considered and even approved formally, or is it
    just for as it were scribbling, more like www-tag</p>

    <p class='phone'><cite>SW:</cite> We could use it to address
    the 'not much came out of this meeting/telcon' problem?</p>

    <p class='phone'><cite>NM:</cite> Would I show stuff to the TAG
    first?</p>

    <p class='phone'><cite>NW:</cite> No -- just as if your
    personal blog<br />
    ... in principle no different from aggregating wrt TAG tag all
    our personal blogs</p>

    <p class='phone'><cite>NW:</cite> and of course we don't all
    have personal blogs</p>

    <p class='phone'><cite>SW:</cite> Musings vs.
    pronouncements</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; <a href=
    "http://dig.csail.mit.edu/breadcrumbs/node/87">Using RDF and
    OWL to model language evolution</a></p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; Submitted by
    connolly on Wed, 2006-02-15</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; ^ a blog item I
    wrote coming out of a TAG ftf</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; <a href=
    "http://www.w3.org/QA/2006/10/arch_qa_loop.html">Web
    Architecture and Quality: closing the loop October 11,
    2006</a></p>

    <h3 id="item03">Dereferencing HTTP URIs, resumed</h3>

    <p class='irc'>&lt;<cite>Stuart</cite>&gt; <a href=
    "http://www.ihmc.us/users/phayes/PatHayes.html">http://www.ihmc.us/users/phayes/PatHayes.html</a></p>

    <p class='phone'><cite>RL:</cite> I will do some rewrites based
    on the input I got<br />
    ... There were some open topics wrt return codes, clarifying
    the http protocol</p>

    <p class='phone'><cite>DC:</cite> Are you prepared to edit in
    that direction?</p>

    <p class='phone'><cite>RL:</cite> Probably, but it depends on
    the extent and direction of any additions</p>

    <p class='phone'><cite>DC:</cite> I'm attracted by the idea of
    looking at something from the customer perspective, what advice
    do we give to people who want to name things<br />
    ... Does the current draft do this?</p>

    <p class='phone'><cite>RL:</cite> Yes, but it's not the
    headline</p>

    <p class='phone'><cite>DC:</cite> I could get behind either
    explaining our original decision or giving guidance about
    choosing names</p>

    <p class='phone'><cite>TBL:</cite> I can only go with 'the
    original decision' unless we expand to cover at least 301 and
    302</p>

    <p class='phone'><cite>SW:</cite> I think the title is wrong --
    the HTTP spec tells us how to dereference URIs<br />
    ... Email thread on www-tag is useful, maybe</p>

    <p class='phone'><cite>HST:</cite> I liked the point that a 200
    response code _asserts_ that the URI identifies an information
    resource, it doesn't _make_ what it identifies _be_ an
    information resource</p>

    <p class='phone'><cite>DC:</cite> [decision tree for giving
    URIs to things]</p>

    <p class='phone'><cite>SW:</cite> Back to the email thread --
    the snapshot of the state issue is interesting. . .</p>

    <p class='phone'><a href=
    "http://lists.w3.org/Archives/Public/www-tag/2007May/0058.html">
    http://lists.w3.org/Archives/Public/www-tag/2007May/0058.html</a></p>

    <p class='phone'>[the URI/URIref distinction brief rathole]</p>

    <p class='phone'><cite>DC:</cite> (and TBL) corner cases wrt
    information resource: e.g. integer, WSDL interfaces<br />
    ... Document vs. Information resource</p>

    <p class='phone'><cite>TBL:</cite> RDF graph is not a
    document</p>

    <p class='phone'><cite>NM:</cite> But we can convey the essense
    of a graph in a message</p>

    <p class='phone'><cite>TBL:</cite> It's the same as the
    difference between a document and a parse tree</p>

    <p class='phone'><cite>HST:</cite> Back to the units example --
    <a href=
    "http://www.example.org/.../units">http://www.example.org/.../units</a>
    -&gt; application/rdf+xml -- identifies what? An RDF graph?</p>

    <p class='phone'><cite>TBL:</cite> no -- identifies the
    document == the information conveyed by that RDF graph</p>

    <p class='phone'><cite>SW:</cite> Two meanings of 'document' --
    got to be careful about that</p>

    <p class='phone'><cite>NM:</cite> The last chapter definitely
    comes after the first, but that's not true about e.g. rows in a
    DB</p>

    <p class='phone'><cite>HST:</cite> That's SW's point</p>

    <p class='phone'><cite>DC:</cite> So this brings me back to the
    question of when you can return 200<br />
    ... What about individual XML elements, e.g.
    "&lt;q&gt;....&lt;/q&gt;" ?<br />
    ... [disagreement among DC, TBL, HST]</p>

    <p class='phone'><cite>HST:</cite> In DC's picture, the
    'document' in "Document-like" is document-sub-1 -- something
    linguistic, in other words<br />
    ... No, that's wrong, because that appears to descriminate
    against e.g. image/jpg or audio/mp3, which we shouldn't do</p>

    <p class='phone'><cite>TBL:</cite> So I think it's clear that
    classes and properties are not information resources</p>

    <p class='phone'><cite>SW:</cite> Norm's document [photo here?]
    is an information resource. What the status of the subject of
    the RDF description therein is a different question</p>

    <p class='phone'><cite>DC:</cite> I don't agree wrt class and
    properties -- I have counterexamples in mind<br />
    ... In summary, when it's clear things are/are not information
    resources, name them as you like and return 200/either package
    them and use # (and 200) if there are a modest number, or name
    them individually and do the 303 thing</p>

    <p class='phone'><cite>SW:</cite> I'm not sure about what the
    GRDDL case is, but does the same question arise with
    client-side application of a stylesheet?</p>

    <p class='phone'><cite>NM:</cite> How does this raise a
    question?</p>

    <p class='phone'><cite>DC:</cite> As HST asked yesterday, the
    question is how/why do same-document URIrefs work (e.g.
    href="#foo") in stylesheet output</p>

    <p class='phone'><cite>NM:</cite> Simple case: HTTP GET, 200,
    media type is well-known, fragids identify secondary resources,
    all cool<br />
    ... Harder case -- HTTP GET, 200, media type is xml, there's a
    stylesheet, result of ss application seems like a different
    media type, so we now have something rather different than the
    message</p>

    <p class='irc'>&lt;<cite>DaveO</cite>&gt; I asked about the
    relationship between the "many things" case tying into Web 2.0
    with many "embedded" things..</p>

    <p class='irc'>&lt;<cite>DaveO</cite>&gt; And particularly,
    does this guidance apply to Web 2.0 things like Google maps</p>

    <p class='phone'><cite>DC:</cite> Not the same as the GRDDL
    case, which is, does #jackson refer to the HTML paragraph or
    the baseball player</p>

    <p class='phone'><cite>NW:</cite> I tend to think of fragids as
    identifying something 'in' the document, but of course e.g.
    Google Maps could have a very small Javascript document whose
    URI was, say, .../map, and the code interprets a fragid to
    focus on any point in the world<br />
    ... The WordNet bug is what we want to avoid, namely,
    retrieving all of WordNet in order to deal with
    .../wordnet#democracy</p>

    <p class='phone'><cite>TBL:</cite> If DC's proposal involves a
    title change, I'm opposed to the change</p>

    <p class='phone'><cite>SW:</cite> My understanding is that it
    does</p>

    <p class='phone'><cite>RL:</cite> I wasn't planning to make a
    title change yet</p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; Note that six photos
    of diagrams from the whiteboard are now available on the Web.
    Yes, for uninteresting reasons, the first one has an extension
    of uppercase JPG and the others have the friendlier jpg</p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.JPG">http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.JPG</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg</a></p>

    <p class='phone'><cite>RL:</cite> and was not planning to fill
    in more wrt 301, 302 etc. yet</p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; ARGH, those are
    wrong...trying again:</p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagWedDiagram1.JPG">http://www.w3.org/2001/tag/2007/05/TagWedDiagram1.JPG</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagWedDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagWedDiagram3.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram1.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram2.jpg</a></p>

    <p class='irc'>&lt;<cite>Noah</cite>&gt; <a href=
    "http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg">http://www.w3.org/2001/tag/2007/05/TagThursDiagram3.jpg</a></p>

    <p class='phone'><cite>TBL:</cite> I want to cover the space of
    response codes (and sequences of them)</p>

    <p class='phone'><cite>DC:</cite> Why should this include 301
    or 302?</p>

    <p class='phone'><cite>TBL:</cite> because I need to know what
    cases my code needs to deal with</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; (ht, which of the
    .jpg's above is the proposed table?)</p>

    <p class='phone'>Table is from yesterday</p>

    <p class='phone'>I haven't looked in yesterday's log yet to
    findit</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; the table seems to
    be <a href=
    "http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg">http://www.w3.org/2001/tag/2007/05/TagWedDiagram2.jpg</a>
    ; the cells are blank.</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; I'm OK for TimBL
    to take an action to write it up, and we'll review it.</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; ok I'm OK for rhys
    to give it a try</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; Diagram3 has some
    stuff.</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; IH: perhaps: good
    practice: design a language so that revisions to the language
    don't cause problems for user agents</p>

    <h3 id="item04">Version Identification</h3>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; Scribe: Dan
    Connolly</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; ScribeNick:
    DanC_lap</p>

    <p class='phone'>IH stops by</p>

    <p class='phone'><cite>IH:</cite> perhaps: good practice:
    design a language so that revisions to the language don't cause
    problems for user agents</p>

    <p class='phone'>taking a look at <a href=
    "http://www.w3.org/TR/webarch/#pr-version-info">http://www.w3.org/TR/webarch/#pr-version-info</a></p>

    <p class='phone'><cite>DO:</cite> so perhaps the version
    information technique should be subordinated under "plan for
    extensions, compatibility... "<br />
    ... this section of /TR/webarch resulted from a snapshot of the
    versioning finding from years ago; the versioning finding has
    come along way since then; perhaps there's a better snapshot to
    take from<br />
    ... we could update /TR/webarch or publish separately or
    whatever</p>

    <p class='phone'><cite>NM:</cite> so re version identification,
    we're not defending the webarch/#pr-version-info strongly as
    written<br />
    ... right?</p>

    <p class='phone'>(many nods)</p>

    <p class='phone'><cite>TVR:</cite> if we had a blog...</p>

    <p class='phone'><cite>DanC:</cite> we can get one for the cost
    of a request...<br />
    ... to the systems team</p>

    <p class='phone'>(NM got some clarification on writing a blog
    item after review by the TAG; DanC needs a few more parameters
    before requesting a blog get set up)</p>

    <p class='phone'><cite>DO:</cite> I'd like us to follow up on
    the details of the versioning techniques...
    costs/benefits...</p>

    <p class='phone'><cite>NM:</cite> do we have an errata
    process?</p>

    <p class='phone'><a href=
    "http://www.w3.org/2001/tag/webarch/errata.html">http://www.w3.org/2001/tag/webarch/errata.html</a></p>

    <p class='phone'><cite>DO:</cite> putting it there isn't
    enough<br />
    ... I'd like to put it right in /TR/webarch ... but maybe it's
    not worth the cost of a WD</p><a name="action01" id=
    "action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> NDW to note a problem near
    webarch/#pr-version-info in the errata [recorded in <a href=
    "http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]</p><a name="action02"
    id="action02"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> NM to draft a blog item on
     possible semantics of version identifiers for review and, pending creation of a TAG blog
    mechanism, post it [recorded in <a href=
    "http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]</p>

    <p class='phone'><cite>DO:</cite> continuing discussion of
    section 2.2.2 Forward Compatible ... I ack concerns around
    "processing model" in the Good Practice note</p>

    <p class='phone'><cite>NM:</cite> "ignore what you don't
    understand" removes the possibility that unknown tags might
    appear in the DOM</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; HTML 2.0 says
    markup in the form of a start-tag or end-g, whose generic
    identifier is not declared is mapped to nothing during
    tokenization.</p>

    <p class='phone'><cite>NM:</cite> if you'd written the "ignore
    tags you don't understand" part of the HTML spec knowing the
    TAG versioning teminology, let's think about how you'd do
    it...</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; HTML 2.0 also says
    ".. the installed base of HTML user agents supports a superset
    of the HTML 2.0 language by reducing it to HTML 2.0:</p>

    <p class='phone'><a href=
    "http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2.1">http://www.w3.org/MarkUp/html-spec/html-spec_4.html#SEC4.2.1</a></p>

    <p class='phone'><cite>DO:</cite> the HTML 2 spec follows this
    model quite closely... it gives a substitution model...</p>

    <p class='phone'><cite>NM:</cite> but this isn't the only way
    to do it...</p>

    <p class='phone'><cite>DC:</cite> this has happened before...
    these good practice notes are being read as applying in all
    cases, where it's clear that you (DO) meant them as menu
    options</p>

    <p class='irc'>&lt;<cite>Norm</cite>&gt; Ok.</p>

    <p class='phone'><cite>NM:</cite> the semantics you define for
    every [lots more words that made the scribe forget these]</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; IH makes the point
    that the "text" case is actually a very small case, it's always
    generated by code, no "document" or "text"</p>

    <p class='phone'><cite>IH:</cite> question... what's the
    audience? spec authors? [yes] what's a text? [sequence of
    characters] well, the HTML5 semantics hang on the tree, not on
    the texts. we don't always even have a text</p>

    <p class='phone'><cite>DanC:</cite> but you have to say what
    happens when you start with a text, right?</p>

    <p class='phone'><cite>IH:</cite> yes, but that's more of a
    corner case</p>

    <p class='phone'><cite>DanC:</cite> you've got a harder problem
    than the one we're advising on so far</p>

    <p class='phone'><cite>NM:</cite> yes, synthetic infosets
    matter, etc.</p>

    <p class='phone'><cite>IH:</cite> there are some DOMs that
    can't be serialized. [SKW: example?] a comment that contains
    two dashes in a row. a table inside a p</p>

    <p class='phone'><cite>NM:</cite> while the case of no network
    connection, totally synthetic DOM is important, we've been
    focussed on the large scale case where text comes over the
    wire</p>

    <p class='phone'><cite>HT:</cite> while using character
    sequences vs abstract syntax is somewhat arbitrary, I don't
    think much of this would change if we switched to abstract
    syntax</p>

    <p class='phone'>[missed some]</p>

    <p class='phone'><cite>HT:</cite> consider
    &lt;banana&gt;...&lt;/banana&gt; ... with style...</p>

    <p class='phone'><cite>IH:</cite> yes, it's gets styled</p>

    <p class='phone'><cite>NM:</cite> that's why I don't like the
    substitution model as a "MUST"</p>

    <p class='phone'><cite>DO:</cite> ack.</p>

    <p class='phone'><cite>TimBL:</cite> [missed]</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted
    to suggest that readers are going to need more of a
    story/example for 2.2.2... (terminology has the story, but I'd
    like that to be inessential)</p>

    <p class='phone'><cite>DO:</cite> reasonable suggestion</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; Rhys, you wanted to
    say its not a must ignore, its a substitution rule</p>

    <p class='phone'><cite>DanC:</cite> hmm... not clear...</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; dorchard, you wanted
    to propose some rewording during a break</p>

    <p class='phone'><cite>DO:</cite> concerning 5 Identifying and
    Extending Languages... stipulate "A fundamental ... determine
    the language" needs work...<br />
    ... perhaps I should move some of [this material in section 5]
    up?<br />
    ... I could try a edit in a break</p>

    <p class='phone'><cite>DanC:</cite> sounds good; how about
    skipping to section 3 for the remaing few minutes before the
    break</p>

    <p class='phone'><cite>DO:</cite> stipulate in 3.3
    "substitution... required..." needs work.</p>

    <p class='phone'><cite>SKW:</cite> I wonder if these are
    requirements...</p>

    <p class='phone'><cite>HT:</cite> "Candidate"
    requirement...</p>

    <p class='phone'><cite>DO:</cite> makes sense... s/Can ...?/ to
    /.../<br />
    ... [summarizing the draft] it continues with a dozen or so
    requirement questions, then raises design questions, then
    surveys several languages showing how they answered the design
    questions.</p>

    <p class='phone'><cite>DanC:</cite> consider moving one of them
    up</p>

    <p class='phone'><cite>DO:</cite> or carrying one of them...
    maybe HTML... thru</p>

    <p class='phone'>[BREAK]</p>

    <p class='irc'>&lt;<cite>Norm</cite>&gt; scribenick: Norm</p>

    <p class='phone'>Reconvene</p>

    <p class='phone'><cite>DO:</cite> I did a quick rewrite of
    2.2.2, Forwards Compatible</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; DanC_lap, you wanted
    to note that &lt;img&gt; is a pretty bad example of forward
    compatibility</p>

    <p class='phone'><cite>DC:</cite> The alternate text should
    have been content, not in an attribute</p>

    <p class='phone'><cite>DO:</cite> I like it because it's not
    tokenized if the img isn't recognized</p>

    <p class='phone'><cite>DC:</cite> Users don't like to have
    images ignored, they want to see the alt text.</p>

    <p class='phone'><cite>DO:</cite> I'm talking about HTML
    2.0.</p>

    <p class='phone'><cite>NM:</cite> This is what I was trying to
    say before: there's a question of what information is available
    and what the application expectations are.</p>

    <p class='phone'><cite>DC:</cite> It's a bad example of
    extensibility.<br />
    ... The strong tag is a better example</p>

    <p class='phone'><cite>DO:</cite> Maybe img isn't a good
    example of a system, but it's a good example of a particular
    set of choices<br />
    ... We can point out the flaws later.</p>

    <p class='phone'><cite>DC:</cite> I think img is a much better
    example of backwards compatibility</p>

    <p class='phone'><cite>NM:</cite> I'm a little concerned about
    the first GPN: fowards-compatibility requires extensibilyt
    rule: Any language intended for forwards-compatible versioning
    MUST have extensibility.<br />
    ... But Henry provided a counter example yesterday: a language
    that gets smaller.<br />
    ... Ten features become five; and that first language had no
    extensibility model.<br />
    ... I think you have to change from any to most.</p>

    <p class='phone'><cite>DO:</cite> I'd like a MUST</p>

    <p class='phone'><cite>DC:</cite> Don't say should or must, say
    "this is a pattern that is known to work well"</p>

    <p class='phone'><cite>HT:</cite> If you anticipate your
    language evolving by adding new features, then you need an
    extensibility rule.</p>

    <p class='irc'>&lt;<cite>DanC_lap</cite>&gt; (agenda request,
    sorta... I started exploring an alternative set of definitions
    that re-package the accept/defined stuff. I didn't really
    finish my exploration, but folks might find it interesting. I
    guess I should have showed it to Noah during a break. I wonder
    if it's worth meeting time)</p>

    <p class='phone'><cite>DO:</cite> WS-Security does not allow
    for forward compatibility; it allows extension but says you
    must fault if you don't understand the extension.<br />
    ... And you need to say both parts; you have to provide
    extensibility *and* you must say what it means when one is
    encountered.</p>

    <p class='phone'><cite>NM:</cite> Many languages are understood
    in terms of "the stuff I understand" and "this other
    stuff"<br />
    ... Ian's earlier example of "banana" tags was a good example.
    They get added to the DOM, they get styled by CSS. Etc. I could
    have said that *all* these tags were in the language.</p>

    <p class='phone'><cite>TV:</cite> When browsers implement XBL,
    this will get even more interesting. You'll be able to provide
    both style and interaction.</p>

    <p class='phone'><cite>DO:</cite> It feels different to
    me.<br />
    ... I think when people think about extensibility, they think
    about designing a language with the things that they know and
    they say very little about the other stuff.</p>

    <p class='phone'><cite>NM:</cite> Part of our role is to
    educate people; if what we discover with CSS and XBL is that
    you might be fooling yourself, it's more subtle than you think.
    We should think hard about telling that story.</p>

    <p class='phone'><cite>TV:</cite> This is not much different
    from moving code around.<br />
    ... You can say anything is allowed, then you can say that only
    three namespaces are allowed, etc.</p>

    <p class='phone'><cite>NM:</cite> Bananas can be styled
    differently from Peaches; they aren't strictly synonyms.</p>

    <p class='phone'><cite>DO:</cite> So items in the accept set,
    not the defined text set, may have a certain amount of
    processing associated with them.</p>

    <p class='phone'><cite>NM:</cite> We're going in circles.</p>

    <p class='phone'><cite>SW:</cite> Two questions: 1. do we have
    a test for "MUST have extensibility"? Can we tell if a language
    does or doesn't have extensiblity? And 2. what about any
    language?<br />
    ... We've been talking about HTML 2.0 as a language and HTML
    3.0 as a language, and also an abstract language called HTML of
    which HTML 2.0 is a version.</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; Definition:
    Extensible if the syntax of a language allows information that
    is not defined in the current version of the language.].</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; from
    versioning</p>

    <p class='irc'>&lt;<cite>dorchard</cite>&gt; prefix with
    Languages are defined to be</p>

    <p class='phone'><cite>SW:</cite> I asked if we have a test. Is
    that a test?</p>

    <p class='phone'><cite>DO:</cite> HTML is extensible because
    banana isn't defined but it is allowed</p>

    <p class='phone'><cite>NM:</cite> I'd approach it differently:
    I'd say they were all in the language but it's extensible if a
    more interesting definition can be provided later.<br />
    ... For example, he allows bananas and he allows CSS styling.
    What could he do next?<br />
    ... Would it be compatible if they were changed to being block
    by default?<br />
    ... I think you have to look at the individual languages to
    answer some of these questions.<br />
    ... It seems to be that we can add attributes to existing
    elements which is also a kind of extensibility.</p>

    <p class='phone'><cite>SW:</cite> My second question was about
    "any language". It seems to be talking about a family of
    languages.</p>

    <p class='phone'><cite>DO:</cite> I meant any in terms of any
    language that you might want to design for forwards
    compatibility.</p>

    <p class='phone'><cite>SW:</cite> Ok, I see what you mean</p>

    <p class='phone'><cite>DC:</cite> I started exploring an
    alternative set of definitions that re-package the
    accept/defined stuff. I didn't really finish my exploration,
    but folks might find it interesting. I guess I should have
    showed it to Noah during a break. I wonder if it's worth
    meeting time<br />
    ... Nevermind. I don't have the bits.<br />
    ... It's on another machine.</p>

    <p class='phone'><cite>SW:</cite> Worth going further?</p>

    <p class='phone'><cite>NM:</cite> I'm starting to feel a little
    overloaded, I wouldn't like to think this was my last chance to
    comment.</p>

    <p class='phone'><cite>SW:</cite> We could look at the XML
    piece, or we could look at the tag soup work that Henry has
    been doing</p><a name="action03" id="action03"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> NM to write up his paper comments on
    extensibility and versioning [recorded in <a href=
    "http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]</p>

    <h3 id="item05">Henry's work on tag soup</h3>

    <p class='phone'><cite>HT:</cite> I thought instead of telling
    the HTML WG that they should describe HTML 5.0 declaratively, I
    should just do it myself.<br />
    ... I think what we want is "formalized tidy", but tidy is just
    a bunch of C code.<br />
    ... John Cowan's tagsoup is as close as we get.<br />
    ... Tagsoup consists of two parts: a table driven scanner
    (tokenizer). It has a fairly nice declarative interface.<br />
    ... The scanner includes some ability to do fixup.</p>

    <p class='phone'><cite>TV:</cite> I second what Henry says;
    I've looked at the code and it's very nice.</p>

    <p class='phone'><cite>HT:</cite> The second thing you get is
    an improved sequence of angle brackets and text but not yet a
    balanced set of start/end tags.<br />
    ... The second half of tag soup as its written takes a fairly
    complicated description of the language, in terms of ancestry
    and other things, which leaves out a bunch of stuff (like
    cardinality and sequencing) but adds a bunch of other
    stuff.<br />
    ... And doesn't expose the connection between where you are and
    what you do for recovery. They're welded into the code.<br />
    ... It recognizes a half dozen kind of problems, but the
    responses are welded in. I wasn't terribly happy with
    that.<br />
    ... I wanted to expose the fixup rules.<br />
    ... The markup for this is called PYXup which is something like
    the ESIS output from sgmls, if you remember what that
    was.<br />
    ... Tagsoup can be told to simply output the pyx stream instead
    of performing the fixup.</p>

    <p class='phone'>Some discussion of the examples from Henry's
    Extreme Markup Languages 2007 paper</p>

    <p class='phone'><cite>HT:</cite> I can reconstruct all the
    things that tagsoup does with this model</p>

    <p class='phone'><cite>TV:</cite> One question to ask is what
    happens in cases like
    &lt;table&gt;&lt;form&gt;&lt;tr&gt;&lt;td&gt;&lt;/form&gt;&lt;td&gt;...<br />

    ... What's your goal? To make something that's valid or to make
    something that mirrors the behavior of current browsers.</p>

    <p class='phone'><cite>HT:</cite> It has to be the latter.</p>

    <p class='phone'><cite>TV:</cite> Right. But if you look at the
    test cases, you'll find that you don't get a well-formed DOM in
    some of these cases.</p>

    <p class='phone'><cite>HT:</cite> There's no question that the
    current code doesn't do enough. The trick, I think, is to allow
    the recovery actions to be sensitive to annotations in the
    grammar. Table and form are good examples of cases where you
    need annotations.</p>

    <p class='phone'><cite>TV:</cite> In the HTML discussion this
    is tangled up with the script processing.<br />
    ... The folks who don't want declarative rules just don't agree
    with some of the results that the fixup does, particularly in
    the case where script mangles the DOM.<br />
    ... TeX has done a better job of this because you can change
    the \catcode of characters.<br />
    ... In some sense, this is what script is doing. Knuth
    describes this in terms of the mouth and the throat and the
    gullet.<br />
    ... So some changes occur in the "mouth" so they don't get down
    into the "stomach".<br />
    ... The whole formalism argument is going to be thrown out
    unless script can be addressed.</p>

    <p class='phone'><cite>HT:</cite> I don't feel too worried
    about the 90% case of scripting because what the fixup works
    with is a string of start-tag/end-tag tokens.<br />
    ... If you recognize the start script tag you can hand over
    tokenizing to the script engine.</p>

    <p class='phone'><cite>TV:</cite> But you also need to provide
    the token stream you've already seen so that script can munge
    it.</p>

    <p class='phone'><cite>HT:</cite> Right. That's not the 90%
    case.<br />
    ... Ian objected to "scripts must produce balanced tags", but
    my next question would have been, can you live with scripts
    that don't change the preceding tokens.<br />
    ... What I heard Ian say was, "if two browsers do it" it has to
    be in.</p>

    <p class='phone'><cite>TV:</cite> They are caught in a
    hole.</p>

    <p class='phone'>Some more casual discussion begins...</p>


  </div>

  <h2><a name="ActionSummary" id="ActionSummary">Summary of Action
  Items</a></h2><!-- Action Items -->
  <strong>[NEW]</strong> <strong>ACTION:</strong> NDW to note a
  problem near webarch/#pr-version-info in the errata [recorded in
  <a href=
  "http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> NM to draft a
  blog item on possible semantics of version identifiers for review and, pending creation of
  a TAG blog mechanism, post it [recorded in <a href=
  "http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> NM to write up
  his paper comments on extensibility and versioning [recorded in
  <a href=
  "http://www.w3.org/2007/05/31-tagmem-irc">http://www.w3.org/2007/05/31-tagmem-irc</a>]<br />

  &#160;<br />
  [End of minutes]<br />
  <hr />

  <address>
    Minutes formatted by David Booth's <a href=
    "http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
    scribe.perl</a> version 1.128 (<a href=
    "http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
    $Date: 2007/06/11 16:20:53 $
  </address>

  <div class="diagnostics"></div>
</body>
</html>